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EXECUTIVE  SUMMARY 


This  report  summarizes  the  results  from  the  work  of  the  Naval  Construction  Force  (NCF) 
Information  Technology  Working  Group. 

The  NCF  Logistics  Quality  Management  Board  (LOG  QMB)  has  characterized  current 
NCF  logistics  information  technology  (IT)  systems  as  being  partially  implemented  Navy 
systems,  lacking  of  comprehensive  functionality,  relying  on  legacy  or  “home  grown”  systems, 
and  lacking  integration  between  systems.  The  Working  Group  was  established  in  June  2000  to 
investigate  the  current  and  proposed  information  technology  systems  to  support  NCF  logistics. 
In  addition,  the  NCF  LOG  QMB  identified  the  need  to  implement  TOA  management  across  the 
NCF  -  to  include  force  level  table  of  allowance  (TOA)  requirements,  unit/field  level  and 
homeport  local  TOA  inventories,  the  ability  for  management  to  stratify  TOA  requirements 
against  inventories,  and  to  provide  TOA  analysis  to  produce  programming  requirements, 
acquisition  plans,  and  make  purchases. 

The  Working  Group  focused  on  the  IT  systems  to  support  TOA  management  and  current 
Navy  IT  systems  used  by  the  Fleet.  Data  was  collected  by  interviewing  and  issuing  data  calls  to 
NCF  operators.  Subject  matter  experts  were  used  to  obtain  detail  information  concerning 
specific  IT  systems. 

Based  on  initial  investigations,  migration  of  NCF  to  a  fully  implemented  logistics  IT 
solutions  will  be  an  intensive  effort.  This  effort  will  require  a  complete  mapping  of  NCF 
business  processes,  will  involve  numerous  activities  and  likely  require  a  multi-workyear  effort. 
This  effort  should  include: 

•  Map  current  and  desired  NCF  logistic  business  processes 

•  Document  the  maintenance  and  material  management  (3-M)  business  process  currently 

being  employed  by  Amphibious  Construction  Battalion  TWO  (ACB2) 

•  Further  investigate  the  processes  and  capabilities  of  MicroSNAP  modules 

■  Investigate  the  capabilities  of  CTS  module  to  determine  applicable  NCF  employment 
(i.e.,  management  of  augment  tools) 

■  Further  investigate  the  differences  and  similarities  between  MOSS  and  OMMS 
modules 

■  Determine  feasibility  of  creating  a  direct  link  between  MOSS  and  OMMS  in  order  to 
support  the  SCLSIS  loop 

■  Complete  a  business  case  analysis  of  CESE  maintenance  procedure  to  determine  how 
current  business  practices  can  be  modified  to  support  use  of  OMMS 

■  Investigate  the  capability  of  capturing  ERO  historical  data  within  MOSS 

-  Determine  who  would  benefit  from  the  capturing  of  this  data 

-  Determine  what  business  practices  are  in  place  to  use  this  data,  what  are  the  data 
fields  captured,  who  would  use  it,  and  where  would  this  data  be  maintained 

•  Further  investigate  the  processes  and  data  flow  required  for  migration  to  the  Navy 

standard  configuration,  logistics,  and  supply  systems 
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BACKGROUND 


The  Naval  Facilities  Engineering  Service  Center  (NFESC)  is  located  on  the  Naval  Base 
Ventura  County  (NBVC/PH),  Port  Hueneme,  California.  NBVC/PH  is  home  port  to  the  Pacific 
Seabees  and  home  to  Naval  Construction  Battalion  Center  (CBCHUE).  CBCHUE  was  formerly 
known  as  the  Seabee  Logistics  Center  (SLC).  CBCHUE’ s  primary  mission  is  to  provide 
centralized  logistic  support  to  the  Naval  Construction  Force  (NCF)  worldwide.  This  includes 
specialized  engineering,  acquisition,  information  technology,  logistics  support,  and  material 
maintenance  to  the  NCF,  Amphibious  Force,  and  to  other  operating  units. 

NFESC  has  been  working  on  various  asset  information  technology  programs  sponsored  by 
the  Office  of  Naval  Research  (ONR)  and  the  Marine  Corps  Systems  Command,  Amphibious 
Warfighting  Technology  Directorate  (MARCORSYSCOM  AWT).  The  program’s  objectives  are 
to  develop,  test,  and  evaluate  the  hardware  and  software  components  that  will  enable  Navy  and 
Marine  Corps  forces  to  track  and  monitor  equipment  and  supplies  as  they  move  to  and  from 
various  points  of  embarkation  and  debarkation. 

In  June  2000,  the  NCF  Command,  Control,  Communications,  Computer  and  Intelligence 
(C4I)  Quality  Management  Board  (QMB)  formally  established  the  NCF  Information  Technology 
(IT)  Working  Group,  under  the  leadership  of  the  NFESC  with  supporting  roles  from  SLC  and 
both  Naval  Construction  Brigades  (NCB).  The  goal  of  the  Working  Group  was  to  harness  the 
ideas  and  energy  of  the  various  initiatives  and  serve  as  the  subject  matter  experts  on  how  best  to 
continue  data  management  system  development. 

CBCHUE  formally  tasked  NFESC  to  provide  analysis  and  planning  in  support  of  the  Naval 
Construction  Force  (NCF)  Logistics  Information  Technology  (IT)  systems.  The  effort  was  in 
direct  support  of  the  NCF  C4I  QMB  efforts  to  assist  the  NCF  Logistics  QMB  in  improving  the 
NCF  logistics  systems.  The  Working  Group  was  the  conduit  for  ensuring  the  taskings  were 
accomplished.  The  statements  of  work  issued  to  the  NFESC  are  shown  in  Appendix  A  and 
Appendix  B. 

Initial  tasking  was  focused  on  establishing  the  baseline  of  current  IT  systems  used  by  the 
NCF.  As  the  Working  Group  began  meeting  and  performing  investigation,  taskings  were  further 
refined  to  focus  on  two  main  capabilities:  TOA  management  and  operational  logistics.  The  first 
area  of  investigation  for  TOA  management  was  the  MicroSNAP  enhancements  being  developed 
by  the  Second  Naval  Construction  Brigade  (2NCB)  specifically  addressing  TOA  management. 
This  investigation  also  included  the  Weapons  Systems  File  and  Configuration  Data  Management 
procedures.  The  second  area  of  focus  was  the  link  between  the  Maintenance  and  Operations 
Support  System  (MOSS)  and  Organizational  Maintenance  Management  System  (OMMS) 
modules  of  MicroSNAP. 

This  report  documents  the  findings  resulting  from  investigations  performed  from  May  2000 
until  November  2000.  Supporting  documentation  resides  in  the  Appendices  C  through  O. 
Further  information  may  be  obtained  by  contacting  the  NCF  IT  Working  Group  members. 

NCF  IT  Architecture  Mapping 

The  initial  area  of  investigation  was  to  develop  an  IT  architecture  map  demonstrating  the 
current  state  of  NCF  data  management.  The  NCF  IT  systems  have  been  characterized  as  being 
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partially  implemented  Navy  systems,  lacking  of  comprehensive  functionality,  relying  on  legacy 
or  “home  grown”  systems,  and  lacking  integration  between  systems.  The  IT  architecture  map 
was  to  show  all  current  software,  which  applications  are  linked  and  sharing  data,  and  which  ones 
are  currently  under  revision  or  being  replaced.  A  data  call  was  issued  to  functional  users  of  NCF 
IT  systems  users  to  determine  the  current  status.  Functional  users  submitted  input  sheets.  Once 
the  programs  were  identified,  the  subject  matter  experts  of  each  program  were  identified.  A  data 
collection  sheet  was  developed  to  gather  in-depth  capabilities  and  data  structure  from  each 
program  identified. 

The  identified  software  programs  currently  in  use  are  listed  in  the  tables  in  Appendix  C. 
For  the  most  part,  each  software  solution  creates  an  island  of  data.  There  is  minimal 
interconnectivity  among  databases.  The  investigation  of  software  applications  shows  that  there 
are  various  database  “families”  employed  across  the  NCF.  For  example,  MicroSNAP  uses  both 
DOS-  and  Windows-based  platforms  with  FoxPro  database.  NCFMIS  resides  within  a 
mainframe  in  a  DataComm  database.  Homegrown  systems  are  generated  using  Microsoft 
Access  or  Excel.  The  more  recently  implemented  or  developed  programs,  such  as  Maximo, 
PISTOL,  and  Construction  Battalion  Construction  Management  (CBCM),  employ  open 
architecture  format  for  data.  Although  not  currently  established,  interconnectivity  in  the  future  is 
easily  obtained  due  to  the  open  database  structure.  This  wide  variety  of  data  warehousing 
validates  the  fact  that  there  is  no  common  IT  approach  within  the  NCF  for  gathering  and  storing 
data. 

In  particular,  the  NCF  does  not  have  a  single  source  of  TOA  data.  Civil  Engineer  Support 
Equipment  (CESE)  data  is  centrally  located  and  maintained;  however,  non-CESE  data  is 
fragmented  among  the  brigades,  regiments,  and  battalions.  TOA  management  is  accomplished 
through  the  use  of  battalion  or  NCB  developed  spreadsheets  and  databases,  which  do  not  readily 
import  or  export  data.  These  “islands  of  data”  prohibit  data  access,  visibility,  and  reporting;  limit 
analysis  capabilities  to  determine  requirements;  and  do  not  allow  for  automatic  procurement 
within  the  Navy  Supply  system. 


MICROSNAP  INVESTIGATION 

The  next  area  of  investigation  was  the  Navy  Supply  software,  MicroSNAP.  SPAWAR 
Chesapeake  was  funded  by  the  Second  Naval  Construction  Brigade  (2NCB)  to  produce  a 
software  requirements  specification  (SRS)  detailing  the  enhancements  required  in  MicroSNAP  to 
allow  for  management  of  the  TOA  at  the  field  level.  Embedded  in  the  investigation  were  the 
research  of  the  Weapons  Systems  File  (WSF)  and  the  establishment  of  a  Configuration  Data 
Manager  (CDM).  The  CDM  provides  data  to  the  Configuration  Data  Manager  Database  -  Open 
Architecture  (CDMD-OA). 

MicroSNAP  modules 

MicroSNAP  is  a  suite  of  software  modules  developed,  owned,  operated,  and  maintained  by 
SPAWAR.  Users  pay  for  yearly  life  cycle  support  costs.  The  following  are  brief  descriptions  of 
the  individual  MicroSNAP  modules: 

•  SFM  (Supply  and  Financial  Management)  manages  material  requirements,  requisitions, 
receipts,  inventory,  and  financial  data.  This  module  can  be  a  stand-alone  application  or 
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placed  on  a  LAN.  SFM  is  installed  at  57  sites  within  the  NCF.  SFM  is  a  DOS-based 
program.  SFM  Windows  prototype  was  installed  at  2NCB  and  CBU  41 1  in  October  2000, 
for  a  60  to  90  day  evaluation. 

•  SMS  (System  Management  Subsystem)  maintains  site  configuration  and  user  access,  and 
is  the  backbone  of  all  MicroSNAP  applications  and  must  be  present  for  any  other  modules 
to  operate.  Therefore,  it  is  installed  and  operational  at  all  MicroSNAP  SFM  sites.  SMS  is 
a  DOS-based  module,  which  will  need  to  be  upgraded  to  a  Windows-based  version  to 
support  the  SFM  Windows  version. 

•  OMMS  (Organizational  Maintenance  Management  System)  manages  and  helps  control 
organizational-level  equipment  configuration,  maintenance,  and  associated  logistics 
support  data.  This  data  enables  overall  visibility  and  evaluation  of  the  key  factors 
associated  with  maintenance  and  material  management,  such  as  equipment  reliability, 
maintainability,  availability  and  condition;  part  demand  data;  and  maintenance  man-hours. 
A  more  detailed  description  of  OMMS’  capabilities  follows. 

-  Provides  the  Naval  Sea  Systems  Command  (NAVSEA)  an  authorized  means  of 
automating  reporting  procedures  related  to  ships’  maintenance  and  material 
management  (3-M)  requirements  in  accordance  with  OPNAVINST  4790. 

-  Receives  and  sends  data  and  reports  between  sites  participating  in  the  ship 
configuration  and  logistic  support  information  system  (SCLSIS)  data  flow  loop. 

-  Produces  a  wide  variety  of  standard  or  tailored  reports  providing  equipment 
configuration,  equipment  maintenance,  logistics  support  data,  APL,  and  COSAL 
information. 

-  Facilitates  proper  accounting  of  installed,  removed,  modified,  or  relocated  pieces  of 
equipment,  and  maintains  equipment,  Allowance  Parts  List  (APL),  and  Consolidated 
Shipboard  Allowance  List  (COSAL)  data. 

-  Documents  and  monitors  repairs  and  changes  to  existing  equipment. 

-  Supports  maintenance  functions  and  generates  standard  Navy  reports. 

-  Provides  capability  to  order  parts  (also  provides  direct  interface  with  the  Micro  SFM 
subsystem). 

-  Provides  the  capability  to  process  externally  generated  maintenance  actions. 

-  Provides  the  capability  to  generate  and  manage  work  packages. 

This  module  is  required  to  operate  within  the  SCLSIS  loop  if  the  3M  maintenance 
philosophy  is  employed.  It  is  an  integral  part  of  the  SCLSIS  loop,  by  feeding  data  to  the 
CDM  to  the  CDMD-OA  to  the  WSF.  OMMS  automates  the  3M  (maintenance  and 
material  management)  tracking  and  reporting  system  using  the  2K  (ship’s  maintenance 
action)  and  CK  (ship’s  configuration  change  form)  forms.  NCF  units  do  not  currently 
employ  OMMS.  However,  OMMS  is  being  evaluated  at  Amphibious  Construction 
Battalion  (PHIBCB  TWO).  OMMS  is  a  DOS-based  program,  with  a  Windows  version  in 
development. 

•  MOSS  (Maintenance  and  Operations  Support  System)  manages  vehicle  inventory, 
maintenance,  and  operations;  schedules  preventive  and  corrective  maintenance.  MOSS 
provides  a  seamless  interface  with  SFM  if  operating  on  the  same  hardware,  i.e.,  PC 
workstation  or  LAN.  Otherwise  data  exchange  is  via  external  methods,  i.e.,  floppy  disk, 
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e-mail.  MOSS  is  not  capable  of  reporting  into  the  CDMD-OA.  All  data  is  maintained  on 
a  local  level.  MOSS  was  developed  specifically  for  the  NCF  to  manage  CESE 
maintenance.  In  1994,  a  study  determined  the  OMMS  would  not  meet  requirements  of  the 
NCF  to  mange  CESE.  MOSS  was  developed  in  response  to  OMMS  not  meeting  the 
business  process  requirements  of  the  NCF  (See  Appendix  D).  MOSS  generates  an 
equipment  repair  order  (ERO)  as  the  authority  to  perform  work  on  equipment.  The  ERO 
is  used  to  track  the  type  of  repair  for  a  vehicle  and  documents  total  hours  for  direct  labor, 
indirect  labor,  and  inspection.  In  addition,  MOSS  is  uniquely  capable  of  providing 
equipment  operations  and  equipment  dispatch  functions;  however,  it  currently  does  not 
track  NCF  licensing.  MOSS  is  a  Windows-based  module. 

•  CTS  (Custody  Tracking  System)  automates  the  issue,  tum-in/rotatable  pool,  and  custody 
tracking  processes.  CTS  is  an  add-on  to  the  SFM  module.  CTS  was  developed  and 
funded  by  SPECWAR,  as  a  result  of  requirements  to  manage  organizational  clothing. 
CTS  is  currently  installed  at  3NCB  and  Gulfport  for  use  by  the  TO  A  managers.  CTS  is 
not  currently  used  by  battalions.  However,  each  regiment  is  allowed  up  to  five  sites  with 
no  additional  life  cycle  support  costs.  It  was  not  determined  to  what  extent  CTS  is 
currently  used.  CTS  could  be  used  to  manage  augment  tools,  since  they  are  not  managed 
in  a  hierarchical  structure.  CTS  is  a  Windows-based  module. 

•  APEX  is  not  a  MicroSNAP  module,  but  allows  web  viewing  of  MicroSNAP  information. 
APEX  is  a  centralized  data  repository  providing  claimancy-wide  query  capability.  It 
collects  data  from  application  processing  sites,  transmits  data  to  a  collection  facility,  and 
stores  the  data  on  an  Intemet/Intranet  web  server  for  easy  access  by  authorized  users.  This 
data  can  be  queried  over  an  Intranet  or  the  Internet,  thus  providing  visibility  and  a 
consolidated  “snapshot”  of  operating  sites’  data.  Must  use  web  browser  to  use  APEX. 
The  Windows  version  of  APEX  is  currently  being  beta  tested  at  2NCB.  There  is  an  initial 
cost  for  setting  up  the  web  server,  training,  and  data  load  on  the  system  to  initialize  use  of 
APEX.  APEX  requires  an  annual  life  cycle  support  fee.  Any  enhancements  are  funded  by 
the  user  recommending  the  changes. 

•  TOAMS  (Table  of  Allowance  Management  System)  application  is  beginning  to  be 
developed.  When  fielded,  it  is  predicted  to  manage  the  NCF  TOA  and  track  inventories 
throughout  their  life  cycles.  Ultimately,  the  completed  TOAMS  application  will  integrate 
with  other  MicroSNAP  applications  (SFM,  SMS,  MOSS,  OMMS,  and  CTS)  and  external 
interfaces  (APEX).  This  integrated  system  will  handle  supply,  maintenance,  and  TOA 
management.  Development  of  this  module  began  in  July  1999,  with  funding  from  2NCB. 
TOAMS  will  be  a  Windows-based  module. 

TOAMS  Software  Requirements  Specification  (SRS) 

SPA  WAR  developed  an  SRS,  which  is  scheduled  for  final  approval  in  second  quarter 
FY01.  The  MicroSNAP  TOAMS  SRS  follows  these  guiding  principles: 

1 .  Conforms  to  current  NAVFAC  conventions. 

2.  Provides  functionality  that  currently  does  not  exist. 

3.  Shares/exchanges  data  where  such  requirement  exists  rather  than  duplicate  it. 

4.  Usable  by  ATI.  TOA  holders,  not  just  an  NMCB  or  NAVFAC  unit. 

5.  Requirements  are  derived  from: 
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a.  NAVFAC,  NAVSUP  and  NAVSEA  instructions,  publications  and  manuals. 

b.  Other  related  instructions  (example  2/3NCBINST  4400.3). 

c.  Commonly  accepted  CB  cultural  practices. 

d.  Direct  observation  and  participation  in  the  involved  processes. 

The  TOAMS  SRS  defines  the  requirements  needed  to  automate  the  TOA  management 
function.  The  application  described  in  the  SRS  will  be  a  Windows-based  application  that  will 
record,  analyze  and  report  the  status  of  a  particular  unit’s  TOA.  The  application  will  support 
planning  and  budgeting;  inventory  control;  and  asset  management.  The  application  will  use  both 
data  currently  stored  in  existing  MicroSNAP  applications  and  several  new  data  elements  specific 
to  the  TOA.  It  was  determined  since  MicroSNAP  TOAMS  will  share  data  with  multiple 
MicroSNAP  application,  it  was  best  to  create  a  new  application.  Since  TOAMS  will  depend  on 
other  MicroSNAP  applications,  it  is  important  that  the  latest  releases  of  all  MicroSNAP 
applications  are  used  for  site-specific  TOAMS  configurations.  Failure  to  use  up-to-date  releases 
may  interfere  with  the  seamless  interface  between  modules. 

The  TOAMS  effort  began  when  StoreKeepers  (SK)  assigned  to  the  NCF  identified  the  lack 
of  a  TOA  management  system.  The  SRS  was  developed  to  address  the  needs  of  the  SKs 
managing  the  TOA  as  well  as  TOA  operators.  A  concise  effort  was  undertaken  to  gather 
requirements  needed  to  manage  a  TOA.  The  first  step  was  to  identify  all  personnel  and 
functions  which  “touch”  the  TOA.  These  individuals  were  called  “process  owners.”  In  addition, 
interviews  with  current  Battalion  personnel  were  conducted.  A  cross-section  of  personnel  from 
Camp  Moscrip  was  interviewed  for  input.  However,  the  SRS  does  not  consider  the  requirement 
for  maintaining  an  organic  unit  embarkation  capability,  or  support  materials  required  for 
construction  Materials  Liaison  Office(MLO). 

The  final  TOAMS  SRS  should  provide  the  full  definition  of  requirements  necessary  for  the 
field  level  units  to  perform  all  operation  objectives  as  envisioned  by  the  NCF.  If  developed 
correctly,  the  SRS  should  support  the  development  of  software  to  support  field-level  TOA  asset 
management,  regardless  of  the  platform  in  which  the  programming  code  is  developed. 

TOAMS  Cost  and  Timeline 

As  part  of  the  final  SRS,  functional  capabilities  for  TOAMS  will  be  prioritized  by 
criticality.  It  is  probable  that  implementation  will  be  in  phases  based  upon  the  priority  of 
functionality.  Costs  to  develop  the  complete  TOAMS  software  were  estimated  by  SPAWAR  at 
$750,000  and  a  timeline  of  18  months.  This  estimation  was  considered  conservative  and  subject 
to  revision  once  the  final  SRS  is  accepted.  According  to  SPAWAR,  a  draft  POA&M  has  been 
completed.  The  final  POA&M  will  be  completed  after  the  functional  priorities  are  determined 
and  the  SRS  is  accepted.  It  is  anticipated  the  SRS  will  be  finalized  in  CY  2001. 


CURRENT  STATUS  OF  MICROSNAP  WITHIN  THE  NCF 

SFM  and  MOSS  are  the  only  modules  that  are  currently  used  by  the  NCF.  Connectivity 
between  the  two  modules  does  not  currently  exist.  Information  generated  in  MOSS  is  “re¬ 
entered”  in  SFM.  Similarly,  data  generated  in  SFM  is  “re-entered”  in  MOSS. 
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Life  cycle  costs  for  SFM  are  funded  on  a  yearly  basis  and  paid  for  by  each  brigade’s 
mission  management  funds.  Costs  depend  on  the  number  of  sites  utilizing  SFM.  MOSS  was  a 
NAVFAC  funded  program.  All  modifications  and  upgrades  are  the  responsibility  of  the  NCF, 
since  they  are  the  sole  organization  that  uses  MOSS.  Since  MOSS  is  a  NCF  specific  module  of 
MicroSNAP,  further  enhancements  to  MOSS  are  expected  to  be  funded  by  NAVFAC/CBCHUE. 
Proposed  upgrades  to  MOSS  in  the  near  future  are  incorporating  NCF  licensing  and  providing  a 
MOSS/OMMS  link.  The  costs/time  frame/availability  of  funding  to  accomplish  these  tasks  are 
unknown  at  this  time. 

One  utility  untapped  by  the  NCF  is  historical  ERO  data  captured  by  MOSS.  It  is  probable 
that  if  this  function  were  not  used,  it  would  be  phased  out  of  future  versions  of  this  module. 

To  implement  any  other  modules  of  MicroSNAP  will  cost  money  and  time.  SPAWAR 
Chesapeake  provided  an  initial  verbal  estimate  for  installation  and  support  of  OMMS.  The  cost 
estimate  is  $138K  to  install  OMMS  at  all  current  SFM  sites.  Annual  life  cycle  support  fees  will 
be  determined  by  SPAWAR  at  a  future  time.  Preliminary  discussion  indicates  life  cycle  cost 
currently  paid  to  support  the  SFM  module  only  will  increase  to  provide  support  for  the  OMMS 
module. 

Weapons  System  File  (WSF)  and  the  Ship  Configuration  and  Logistics  Support 
Information  System  (SCLSIS) 

The  WSF  serves  as  a  repository  for  information  provided  during  the  provisioning  process. 
It  consists  of  two  sets  of  databases:  WSF  and  CDMD-OA.  The  WSF  is  further  divided  into 
three  separate  database  files:  Level  A,  Level  C,  and  Master  Item  File  (MIF).  Level  A  relates 
Ship  Unique  Identifier  Code  (UIC)  to  Allowance  Parts  List  (APL)  or  Allowance  Equipage  List 
(AEL).  Level  A  also  contains  the  ship’s  configuration  data.  Level  C  relates  the  APL/AEL  to 
parts  and  contains  equipment  configuration  and  technical  data.  There  also  appears  to  be  a  Level 
B  within  the  WSF.  Additional  information  on  Level  B  is  discussed  later. 

CDMD-OA  database  is  a  central  repository  for  configuration  management  data.  Data  is 
updated  electronically  by  the  CDM  via  MicroSNAP  OMMS  module,  which  automatically 
updates  WSF  Level  C.  CDMD-OA  relies  on  a  hierarchical  structure  code  (HSC),  which  is  a  12- 
digit  code  that  functionally  identifies  the  equipment  within  the  system.  The  code  is  based  on  the 
expanded  ship  work  breakdown  structure  and  relates  directly  to  an  APL/AEL  number. 

The  provisioning  process  provides  the  following  information:  equipment  configuration, 
inventory  management,  maintenance  significant  parts,  and  technical  coding.  WSF  provides  all 
supply  and  maintenance  information  registered  against  the  UIC  based  on  configuration  input.  It 
also  includes  repair  parts,  special  tools,  and  support  items  required  for  the  operation;  overhauls; 
maintenance;  and  repair  of  installed  equipment  within  the  units’  maintenance  capability. 

Data  residing  in  the  WSF  drives  configuration  management.  Updates  and  retrieval  of  data 
from  the  WSF  are  an  integral  portion  of  the  SCLSIS  loop,  which  includes  MicroSNAP  OMMS, 
MicroSNAP  SFM,  Configuration  Data  Manager  Database  -  Open  Architecture  (CDMD-OA), 
3-M  database,  and  the  Automated  Shore  Interface  (ASI).  ASI  accepts  externally  generated 
transactions  that  update  both  MicroSNAP  OMMS  and  MicroSNAP  SFM  databases  to  ensure 
synchronization  with  authorized  shore-based  data  managers.  The  objectives  of  SCLSIS  are  to 
establish  and  maintain  accurate  configuration  and  associated  logistic  support  information  for 
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critical  systems  within  the  Navy.  Pictorial  representations  of  data  flow  within  the  SCLSIS  loop 
are  provided  in  Appendix  E. 

Currently,  the  only  portion  of  the  WSF  utilized  by  the  NCF  is  Level  B,  which  houses  CESE 
APL  data.  Level  B  originally  was  designed  to  relate  the  systems  to  the  equipment,  and  is  not 
actively  used  within  the  SCLSIS  loop.  Updates  to  the  CESE  APL  data  are  entered  manually  by 
NAVICP  via  requests  submitted  by  CBCHUE. 

Because  NCF  does  not  use  MicroSNAP  OMMS,  it  is  outside  of  the  SCLSIS  loop.  In  order 
for  the  NCF  to  participate  in  the  WSF  and  the  SCLSIS  loop,  MicroSNAP  OMMS  will  need  to  be 
deployed.  The  following  must  be  considered,  as  a  minimum: 

a.  Establishment  of  a  Configuration  Data  Manager(s)  (CDM) 

b.  Development  of  hierarchical  structure  codes  for  TOA  assets 

c.  Establishment  of  TOA  asset  databases  within  WSF,  each  UIC  requires  a  unique 
database 

d.  Independent  validation  of  TOA  asset  information 

e.  Determination  of  number  of  OMMS  sites  to  be  established 

Due  to  the  complexity  of  the  SCLSIS  loop,  all  the  mechanisms  to  complete  the  SCLSIS 
loop  have  not  been  identified  by  the  NCT  IT  Working  Group.  If  the  NCF  decides  to  utilize  the 
WSF,  further  investigation  is  required  prior  to  developing  an  implementation  plan.  Preliminary 
associated  costs  related  to  the  CDMD-OA,  MicroSNAP  OMMS,  CDM,  and  Automated  Shore 
Interface  are  provided  in  Appendix  F. 


RECOMMENDATIONS 

1.  Further  investigate  the  processes  and  data  flow  required  for  migration  to  the  Navy 
standard  configuration,  logistics,  and  supply  systems. 

If  the  SCLSIS  loop  is  to  be  implemented,  further  investigation  is  required.  Once  the 
complete  SCLSIS  loop  is  understood,  mapping  of  NCF  business  process  relating  to  the 
process  can  begin.  Once  business  processes  are  agreed  upon,  a  migration  plan  can  be 
developed.  Based  on  initial  investigations,  migration  to  a  fully  implemented  SCLSIS 
loop  business  process  will  be  an  intensive  effort.  The  effort  will  involve  numerous 
activities  and  likely  require  a  multi-workyear  effort.  A  possible  source  to  provide  cost, 
time,  and  benefit  estimates  of  the  WSF  is  the  Fitting  Out  and  Supply  Support  Assistance 
Center  (FOSSAC),  which  specializes  in  providing  Naval  forces  with  supply-related 
engineering,  training  and  support  services.  Their  web  site  address  is 
http://www.norfolk.navy.mil/price_fighters/fossac/index.htm. 

2.  Fully  map  current  and  desired  NCF  logistic  business  processes. 

An  intense  investigation  of  NCF  business  practices  in  mission  and  logistics  support  will 
assist  in  identifying  the  IT  systems  that  enhance  the  processes.  After  business  practices 
are  mapped,  IT  systems  can  be  identified  to  enhance  capability  and  an  IT  investment 
plan  can  be  developed. 

3.  Document  the  3-M  business  process  currently  being  employed  by  PHIBCB  TWO. 
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3-M  is  a  well-established  philosophy  within  the  Navy  community.  Documenting  and 
understanding  the  processes  that  are  evolving  at  PHIBCB  TWO  will  facilitate  mapping 
and  implementing  NCF  business  processes. 

4.  Further  investigate  the  processes  and  capabilities  of  MicroSNAP  modules 

a.  Investigate  the  capabilities  of  CTS  module  to  determine  applicable  NCF  employment 
(i.e.,  management  of  augment  tools).  CTS  is  capable  of  tracking  issue/retum  of 
assets.  The  NCF  is  currently  lacking  a  management  tool  for  augment  tools.  Since 
augment  tools  are  not  managed  in  a  hierarchical  structure,  CTS  may  have  the 
capability  to  meet  this  function.  Each  Regiment  is  allowed  up  to  five  sites  with  no 
additional  life  cycle  support  costs. 

b.  Further  investigate  the  differences  and  similarities  between  MOSS  and  OMMS 
modules. 

Document  the  direct  “cross-over”  of  data  elements  between  MOSS  and  OMMS. 
Appendix  G  contains  data  record  comparison  between  OMMS  A-l  record  and  ERO. 
This  record  comparison  is  only  one  small  aspect  of  the  data  comparison  that  needs  to 
be  documented. 

c.  Determine  feasibility  of  creating  a  direct  link  between  MOSS  and  OMMS  in  order  to 
support  the  SCLSIS  loop.  SPAWAR  is  aware  of  the  need  for  the  MOSS/OMMS  link, 
and  has  put  this  requirement  high  on  its  proposed  enhancement  list  for  MOSS. 
However,  the  costs/time  frame/availability  of  funding  are  unknown  at  this  time. 

d.  Complete  a  business  case  analysis  of  CESE  maintenance  procedure  to  determine  how 
current  business  practices  can  be  modified  to  support  use  of  OMMS. 

e.  Investigate  the  capability  of  capturing  ERO  historical  data  within  MOSS.  The  MOSS 
module  captures  historical  data.  However,  at  present  time  data  are  deleted  from  the 
system.  First  step  would  be  to  determine  who  would  benefit  from  the  capturing  of 
this  data.  The  next  steps  would  be  to  determine  what  business  practices  are  in  place 
to  utilize  this  data,  what  are  the  data  fields  captured,  who  would  use  it,  and  where 
would  this  data  be  maintained. 

5.  Employ  a  disciplined  process  to  facilitate  the  NCF  Logistics  IT  solution.  Detailed 
processes  are  employed  in  current  software  development.  Problem  definition  and 
requirements  should  be  defined  in  detail  in  order  to  employ  a  software  solution  that 
meets  the  needs  of  various  levels  of  logistics  supports.  A  point  paper  on  the  subject  of 
software  construction  is  contained  in  Appendix  H. 
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APPENDIX  A 


SOW  for  DOC  N6258300WR40072 


1.  Provide  engineering  and  program  support  for  the  development  of  NCF  Logistics 
Information  Technology  (IT)  Initiative.  This  effort  will  include: 

•  Define  current  NCF  software,  including  POCs,  where  installed  and  operating  capabilities 
and  requirements  met. 

•  Identify  current  IT  initiatives 

•  Establish  NCF  IT  IPT 

•  Identify  areas  that  require  MC  connectivity 

•  Define  preliminary  requirements  for  the  NCF  IT  System 

•  Propose  NCT  IT  Investment  Plan 

2.  Advise  SLC  and  IPTs  of  opportunity  with  MC  asset  information  and  asset  visibility 
under  development  at  the  ESC 

3.  Continue  to  provide  engineering  and  program  support  of  the  ABFC  program. 


A-l 


A-2 


APPENDIX  B 


SOW  for  DOC  N6258300P040002 


Provide  continued  analysis  and  planning  in  support  of  NCF  Information  Technology  (IT).  This 

effort  will  be  in  direct  support  of  the  NCF  C4I QMB  efforts  to  assist  the  NCF  LOG  QMB  in 

improving  NCF  Logistic  Systems.  To  include  but  not  limited  to: 

1.  Validate  current  MSNAP  capabilities.  What  is  it  doing  for  us  today?  What  is  it  doing  for 
others  that  we  don’t  use? 

2.  Research  cost  and  time  to  expand  MicroSnap  capabilities.  What  do  the  2NCB  funded 
MicroSnap  enhancements  give  us?  What  NCF  business  processes  need  to  change  as  a  result? 
What  other  obvious  enhancements  could  be  made? 

3.  Make  specific  recommendation  back  to  LOG  QMB/ESG  on  increased  use  of  MicroSnap. 

4.  Prepare  detailed  cost  estimates,  SME  and  management  resource  recommendations,  and 
proposed  timelines  to  develop  an  NCF  Maximo  TOA  Management  capability  (to  include 
synchronization  with  existing  Navy  financial  and  supply  systems.) 

5  a.  (LOG  QMB  tasking)  Identify  available  FY01  funding  for  software  development. 

5b.  (C4I)  develop  plan  for  obligating  FY01  funding.  Provide  justification  for  FY02  and  out  year 
funding. 
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APPENDIX  D 


SAMMS  EMS/MicroSNAP  II  MDS/OMMS  Evaluation  Report 

Judith  A.  Takahara 
CESO,  Code  1572T 
Nov  18,  1992 


SAMMS  EMS/MICRO  SNAP  II  MDS/OMMS 
EVALUATION 


1.0  PURPOSE; 


The  purpose  of  the  evaluation  is  to  analyze  the  differences  between  the  Micro  SNAP  II 
Maintenance  Data  Subsystem  (MDS),  more  appropriately  called  the  Organizational 
Maintenance  Management  Subsystem  (OMMS),  and  the  SAMM  Equipment  Maintenance 
System  (EMS)  and  to  determine  the  feasibility  of  utilizing  MDS  in  the  Naval  Construction  Force 
(NCF).  There  will  be  a  requirement  to  interface  the  Civil  Engineer  Support  Office  COP  AL  data 
base  with  the  Micro  SNAP  II  System,  for  repair  parts,  which  is  much  the  same  as  the  SPCC 
COSAL  update  feature  of  Micro  SNAP  n. 

2.0  OBJECT: 

The  primary  objective  of  the  evaluation  is  to  prepare  a  report  that  outlines  the  differences 
between  these  two  systems,  and  how  they  relate  to  the  CESE  COSAL’ s.  This  report  will 
ultimately  be  sent  to  the  2nd  and  3rd  Brigades  for  their  review. 

3.0  REFERENCES: 

The  following  materials  were  used  as  references: 

•  CESO  SAMM:  Equipment  Maintenance  System  and  User  Manual 

•  NAVMASSO  Micro  SNAP  E  MDS/OMMS  Subsystem  .MDS/OMMS  Processing 
Flowchart 

•  Micro  SNAP  E  MDS/OMMS  Demo/Overview  provided  by  NA  VMASSO 

•  COMCBP  AC/COMCBLANT  Equipment  Management  Instruction  1 1 200.  IE 

•  SPCCINST  4441.170A 

•  CESO  COSAL  Maintenance  Evaluation  by  Mr.  Seth  Johnson 

4.0  EQUIPMENT  MAINTENANCE  SYSTEM  BACKGROUND: 

The  SAMM  Equipment  Maintenance  System  is  designed  in  accordance  with  the 
COMCBPAC/COMCBLANT  Instruction  1 1200. IE,  also  known  as  the  Red  Book.  EMS  tracks  a 
variety  of  information  about  all  equipment  (primarily  CESE)  assigned  to  the  NCF  and  the 
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Special  Operating  Units  (SOU’s),  including  make,  model,  year,  location,  serial  numbers,  stock 
numbers,  maintenance  history,  attachments,  collateral  equipment,  maintenance  scheduling,  and 
repair  parts  requisitions. 

EMS  is  a  stand-alone  system  and  is  designed  for  use  by  CESE  maintenance  personnel. 
EMS  interacts  with  the  Equipment  Operations  System  on  a  daily  basis;  however,  the  systems  are 
designed  to  function  independently.  The  use  of  two  computers  permits  the  equipment  operations 
personnel  and  the  equipment  maintenance  personnel  maximum  access  to  the  systems  needed  to 
support  their  individual  but  related  functions. 

•  Software  and  Hardware  Requirements; 

Software;  MS-DOS  -  EMS  has  been  tested  with  versions  3.3,  4.01,  and  5.0  however 
other  versions  may  also  be  suitable. 

Hardware:  286/386/486  based  computer  with  compatible  monitor,  and  at  least  2 
megabytes  of  hard  disk  storage 

Optional  Network:  NETBIOS  compatibility.  Tested  on  Novell  Netware,  Artisoft 
Lantastic,  and  3Comm  3+  networks.  EMS  will  probably  work  with  other  NETBIOS  compatible 
networks.  The  SAMMS  multi-user  Bill  of  Material  (BM)  system,  designed  by  Information 
Systems  Technology  Center  (ISTC),  has  successfully  run  on  Banyon  Vines;  so,  I  would  assume 
that  Banyon  Vines  would  support  EMS  since  both  the  EM  and  the  EMS  LAN  versions  were 
designed  by  Information  Systems  Technology  Center  (ISTC)  using  the  same  Data  Driven  system 
concept. 

5.0  MAINTENANCE  DATA  SUBSYSTEM  (MDSVORGANIZATION 
MAINTENANCE  MANAGEMENT  SUBSYSTEM  (OMMS)  BACKGROUND: 

The  Micro  SNAP  D  MDS/OMMS  subsystem,  provides  an  on-line  interactive  3-M 
(Maintenance  Material  Management)  system.  MDS/OMMS  is  developed  according  to  the  3M 
4790.2  instruction  and  provides  Maintenance  and  COSAL  Support  and  Updates.  The  Navy 
utilizes  the  instruction  4790.2K  (2  Kilo)  to  perform  maintenance  actions.  The  MDS/OMMS 
subsystem  includes  3-M  functions  related  to  the  current  Ship’s  Maintenance  Project  Master 
(CSMP)  database.  This  data  base  consists  of  Maintenance  Data  Collection  System  (MDCS) 
actions,  Configuration  Change  (CK)  actions,  and  Work  Center  Work  List  (WCWL)  actions.  The 
Maintenance  Data  Subsystem  is  not  used  by  the  2nd  and  3rd  NCB  units  and  no  action  has  been 
taken  to  get  any  COSAL  data  transferred  to  it. 

The  Micro  SNAP  II  system  has  been  written  to  run  in  both  stand-alone  PC  mode  or  in  a 
multi-user  mode  on  a  NOVELL  LAN  with  multiple  file  servers.  It  is  also  written  to  allow  for 
multiple  Unit  Identification  Codes  (UIC). 

MDS/OMMS  is  designed  for  operation  with  a  minimum  amount  of  dollars  for  repair 
parts  inventory  and  support  on  a  ship.  MDS  serves  as  a  way  to  track  the  equipment  related  to  the 
parts  that  break  in  the  Fleet.  This  information  is  important  because  problems  identified  by  one 
ship  are  often  faced  by  other  ships  throughout  the  fleet  using  similar  equipment. 
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MDS/OMMS  essentially  operates  in  almost  a  paperless  environment,  at  least  that  is  the 
intention;  hence,  not  many  documents  need  to  be  handled.  The  cost  savings  can  be  tremendous. 

•  Software  and  Hardware  Requirements; 

Software:  MS-DOS  5.0,  and  FOXPRO/LAN  Version  1.02  compiled  to  use  FOXPRO 
runtime. 

Hardware:  286/386/486  (386  is  recommended),  2MB  RAM,  9  track  tape  drive,  320  tape 
backup  unit,  and  a  300  MB  hard  disk  drive  (minimum  260  MB). 

Network:  Certified  to  operate  in  a  multi-user  mode  on  a  NOVELL  LAN  (with  multiple 
file  servers). 

6.0  FUNCTIONAL  EVALUATIONS: 

There  are  major  differences  between  the  design  of  the  Micro  SNAP  II  MDS/OMMS 
Subsystem  and  the  design  of  the  SAMM  Equipment  Maintenance  System.  Because  the  two 
systems  are  very  complex,  only  some  of  the  major  design  differences  where  I  see  noticeable 
differences  are  documented.  The  comparisons  that  follow  are  derived  both  from  the  highest 
functional  levels  within  the  two  systems,  and  from  some  of  the  detailed  level  functions  and 
fields.  Some  of  the  major  differences  are  as  follows: 

•  Maintenance  Action  tracking: 

It  appears  that  maintenance  actions  in  both  Micro  SNAP  II OMMS/MDS  and  SAMMS 
EMS  are  tracked  utilizing  similar  methods. 

Micro  SNAP  II  MDS/OMMS  Maintenance  Actions  are  assigned  a  Job  Sequence  Number 
(JSN).  This  is  used  in  association  with  the  Work  Center  to  track  the  maintenance  action.  The 
work  center  is  pre-filled  with  the  user’s  primary  work  center.  The  work  center  and  JSN  are 
combined  to  create  the  Job  Control  Number  (JCN). 

SAMMS  EMS  assigns  an  Equipment  Repair  Order  Number  (ERO  #).  The  first  four 
characters  of  the  JSN  are  two  alpha  characters,  followed  by  two  numeric  characters,  such  as 
AA00.  The  last  four  characters  of  the  ERO  number  are  a  locally  assigned  JSN,  which  runs 
continuously  from  0001  through  9999  for  rotating  and  non-rotating  units,  with  no  regards  for  end 
of  fiscal  year  or  NMCB  BEEP. 

•  Generate  an  Equipment  Repair  Order  (ERO): 

SAMMS  EMS  prepares  and  utilizes  the  ERG  as  the  sole  authority  to  perform  work  on 
equipment  in  the  following  categories:  scheduled  maintenance  (PM),  interim  repairs  exceeding 
1.0  man-hours  or  which  require  repair  parts,  modernization  or  alteration  of  equipment,  and 
deadline  cycling  or  preservation  of  equipment.  The  ERO  is  used  to  track  the  type  of  the  repair 
for  a  vehicle,  and  document  and  total  the  hours  for  direct  labor,  indirect  labor,  and  inspection, 
which  equates  to  the  total  time  an  item  of  equipment  is  out  of  service. 
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Indirect  labor  is  how  much  time  it  takes  for  everyone  involved  in  the  preliminaries  for  the 
repair  and  before  the  actual  repair  is  done.  The  following  people  would  charge  their  time  to 
indirect  labor:  Inspector,  Tech  Librarian,  DTO  Clerk,  PM  Clerk,  and  Parts  Expediter.  Direct 
Labor  accounts  for  the  mechanics  time. 

Other  items  listed  on  the  ERO  (but  not  limited  to)  are:  ERO  number,  USN/ID  number, 
equipment  cost  code,  activity  UIC,  job  order  number,  location/allowance,  type  repair,  meter 
readings,  make,  engine  mfg.,  engine  model,  chassis  serial  number,  function  code,  work 
description,  pri/sec,  manhours  (actual  and  estimate)  and  estimated  mat’l  cost. 

•  Create  a  Maintenance  Action  4790.2K  (deferral): 

In  Micro  SNAP  II MDS/OMMS,  a  4790.2K  (deferral)  must  be  opened/entered  to  begin  a 
Maintenance  Action.  The  4790.2K  contains  such  information  as  the  work  center,  equipment, 
what’s  wrong,  who’s  repairing  the  equipment,  manhours  required,  etc.  There  is  a  filter  screen 
that  is  used  to  initiate  the  Maintenance  Action.  The  RIN  (Record  Identifier  Number),  APL,  or 
EIC  can  be  selected  in  this  screen  if  it’s  known.  After  the  filter  screen  helps  the  user  to  obtain 
the  correct  APL,  the  ADD  Deferred  Maintenance  Action  screen  (2K)  must  be  entered.  It  looks 
just  like  a  2K  in  the  3M  Manual.  After  all  the  data  is  entered  on  the  Add  screen,  the  JSN  is 
automatically  assigned.  The  Maintenance  Action  gets  added  to  the  Current  Ships  Maintenance 
Plan  (CSMP)  data  base  file. 

The  3M  Coordinator  (Repair  Officer,  Engineer  Officer,  etc.)  determines  if  the  job  can  be 
accepted.  This  coordinator  assigns  the  Maintenance  Action  to  a  work  center.  This  assignment  is 
not  done  in  the  MDS/OMMS  subsystem.  The  3M  coordinator  keeps  the  CSMP  data  accurate. 

If  a  deferred  item  is  an  Inspection  Survey  (ENSURV)  item  (safety  deficiencies  noted 
during  inspections),  an  indicator  is  set  to  indicate  that  it’s  an  INSURV,  and  the  only  options  that 
can  be  used  are  Deferred  MDCS  Action,  Completed  MDCS  Action,  and  Add  a  Job  by  JCN. 

An  INSURV  item  in  SNAP  might  compare  to  a  Safety  item  in  SAMMS  EMS.  In 
MDS/OMMS,  the  INSURV  is  performed  prior  to  the  overhaul  of  the  ship.  Engineers  familiar 
with  the  ship,  perform  an  inspection  and  review  all  the  3M  maintenance  records.  The  main 
purpose  of  the  INSURV  is  to  make  sure  the  ship  is  doing  its  job  in  maintaining  the  ship. 

In  the  EMS  system,  a  safety  item  (vehicle)  has  to  be  fixed  immediately.  It’s  only  held 
until  the  part  is  received.  The  vehicle  can’t  be  dispatched  until  it’s  fixed.  Dispatch  checks  the 
vehicle  and  if  the  deficiency  has  not  been  fixed,  the  vehicle  gets  sent  back  to  the  mechanic.  This 
process  gets  repeated  until  the  repair  is  done  correctly. 

•  Create  a  Maintenance  Action  4790.CK: 

In  Micro  SNAP  E  MDS/OMMS,  a  4790.CK  (Configuration  Change)  is  generated  for  an 
addition,  deletion,  or  movement  of  equipment.  For  new  equipment,  the  CK  is  generated  for  the 
purpose  of  obtaining  maintenance,  parts  support,  and  technical  manuals.  Cards  will  be  generated 
that  detail  what  needs  to  be  done  to  maintain  the  equipment.  The  CK  maintenance  action  causes 
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the  Weapons  Systems  File  (WSF)  to  be  updated,  so  it’s  known  what  equipment  is  onboard  and 
where  it  is  located. 

In  SAMMS  EMS,  the  configuration  change  information  gets  recorded  in  the  Equipment 
History  File.  A  Maintenance  Action  (which  does  not  exist  in  the  EMS  system;  only  an  ERO) 
does  not  get  generated  to  reflect  a  change  in  equipment.  There  are  no  external  files  other  than 
the  files  in  the  Equipment  Operations  system  that  receive  Equipment  History  File  “change” 
information.  EMS  does  not  receive  updates/changes  in  the  form  of  ASI  processing  as  does  the 
SNAP  system. 

A  deletion  would  be  processed  when  a  piece  of  equipment  gets  sent  to  disposal  because  it 
has  a  status  code  that  indicates  it’s  not  in  shop,  it’s  not  ready,  and  it  can  not  be  fixed. 

•  Create  a  Ships  Force  Work  List  (SWFL)  Maintenance  Action: 

In  Micro  SNAP  II MDS/OMMS,  the  SWFL  is  used  to  add  non-  maintenance  type  actions 
and  document  manhours  for  repairs  that  are  not  related  to  equipment  configuration.  No  APL  is 
listed  for  these  actions.  Overdue  SFWL  actions  (those  open  for  a  length  of  time  exceeding  the 
maximum  number  of  days  set  by  the  3-M  Coordinator)  may  be  changed  to  a  deferred  MDCS 
action. 


In  SAMMS  EMS  there  is  no  comparable  feature  to  track  non-  maintenance  type  actions; 
it’s  only  responsible  for  tracking  repairs  made  on  the  equipment  (vehicles). 

•  Direct  Turnover  (DTP): 

In  Micro  SNAP  II  MDS/OMMS,  a  maintenance  action  generates  a  DD1250.  When  the 
mechanic  opens  up  a  2K  job,  and  chooses  to  order  parts  (repair  parts  or  consumables),  the  NSN’s 
are  displayed  for  an  APL.  The  appropriate  NSN’s  are  chosen,  and  once  this  process  is  complete 
the  parts  are  reviewed  in  the  Tech  Edit  ((Supply  and  Financial  Management  (SFM)  module) 
process.  This  process  checks  the  NSN,  COG,  ill,  price,  etc.,  and  determines  whether  the  parts 
are  available,  or  if  they  need  to  be  ordered  DTO.  The  information  gets  sent  back  to  the  division 
requesting  the  items  for  approval  to  issue  or  order  the  items.  Once  the  approval  is  made,  the 
1250’s  can  be  generated  and  automatically  printed.  If  an  item  is  urgent  such  as  a  CAS  REP  or  an 
ANORS,  the  storekeeper  can  manually  enter  the  1250  data  and  can  then  print  a  1250  form.  The 
forms  are  sent  to  the  requisitioning  (financial)  storekeeper  to  order  the  items.  DTO  requisitions 
are  eventually  output  to  DAAS. 

When  a  requisitioned  items  is  received,  the  Supplementary  Address  on  the  1348  will 
indicate  where  to  send  the  item.  When  an  item  is  received  in  the  SFM  module,  the  item  is 
marked  as  received  in  the  MDS  module,  and  if  it’ s  a  Not-In-Stock  or  Not  Carried  item,  the 
demand  is  recorded  (entered)  in  the  demand  history  files. 

In  SAMMS  EMS,  a  DTO  requisition  (Form  1250)  is  processed  (handwritten)  if  parts  are 
needed  and  they  aren’t  available.  The  DTO  option  is  keyed  to  the  USN  and  the  requisition 
number.  A  temporary  requisition  number  gets  assigned  to  the  requisition.  When  a  copy  of  the 
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requisition  comes  back  from  Supply,  it  will  Dave  the  permanent  requisition  number  on  it.  The 
temporary  requisition  number  is  replaced  and  recorded  with  the  permanent  requisition  number, 
along  with  any  Supply  status  information.  A  multi-purpose  data  entry  screen  is  used  to  order, 
receive,  and  issue  DTO  parts.  EMS  automatically  purges  DTO’s  with  an  issue  date  older  than  30 
days.  EMS  does  not  have  an  automated,  print  1250 form  feature. 

Note:  There  is  no  automated  requisition  status/input  from  SUPMIS  in  EMS.  The  option 
(connection)  was  never  established  or  programmed. 

For  deadlined  equipment,  the  vehicle  can’t  be  used  until  the  DTO  part  is  received  and  the 
vehicle  gets  repaired.  The  DTO  clerk  maintains  the  deadline  file  and  the  deadline  status  file. 

•  Allowance  Parts  Lists  (APL’s): 

In  Micro  SNAP  II MDS/OMMS,  the  ship’s  equipment  file  contains  a  summary  of  the 
installed  equipment.  The  COSAL  file  contains  the  APL  and  AEL  information  related  to  each 
equipment  or  system. 

Micro  SNAP  II  is  heavily  tied  into  the  APL’s.  When  you  order  parts,  you  must  have  an 
APL  number.  An  exception  is  when  the  item  is  not  related  to  an  equipment  configuration  such 
as  ordering  non-maintenance  related  supplies  that  have  no  associated  APL’s.  Some  non¬ 
maintenance  items  can  be  items  such  as  cleaning  compounds,  rags,  oils,  tools,  etc.  These  can  be 
carried  items. 

The  SAMMS  EMS  does  not  track  the  APL’s.  The  mechanic  keeps  track  of  the  parts 
required  to  repair  equipment.  There  can  be  3  APL’ s  noted  in  the  Equipment  History  file,  but  the 
Equipment  Maintenance  System  is  not  heavily  tied  to  the  APL. 

•  Preventive  Maintenance: 

There  is  no  Preventive  Maintenance  scheduling/tracking  in  Micro  SNAP  II  MDS/OMMS; 
however,  on  every  ship  there  is  a  Planned  Maintenance  System  (P MS),  which  is  a  series  of  cards 
used  to  perform  maintenance  on  all  pieces  of  equipment.  This  PMS  is  separate  from  the  SNAP 
system,  but  acts  as  a  front  end  if  maintenance  can’t  be  accomplished  at  the  PMS  level.  If  there  is 
a  problem  and  it  can’t  be  fixed  in  a  certain  amount  of  time  (a  time  frame  prescribed  by  the 
TYCOM,  such  as  24  hours,  1  week,  or  30  days),  and  the  repair  requires  some  type  of  assistance 
from  an  activity  external  to  the  ship,  the  repair  is  documented  in  the  PMS  as  being  deferred,  and 
it  is  entered  (opened  up)  in  Micro  SNAP  II  MDS/OMMS  as  a  deferral  (2K).  Deficiencies  that 
have  not  been  corrected  and  are  reported  by  INSURV  would  also  be  deferred.  When  logging 
man  hours,  a  2K  or  SFWL  can  be  used  to  track  the  manhours.  You  can  only  track  manhours  that 
are  used  to  do  a  PM.  This  information  can  be  put  in  the  remarks  block. 

MDS/OMMS  tracks  maintenance  that  can  not  be  done  properly.  There  are  many  reasons 
for  the  deferral  such  as  there  is  no  one  on-board  who  can  fix  the  problem  (training  may  be 
needed),  or  there  are  no  parts.  If  the  part  is  not  in  the  MDS  subsystem,  and  there  is  a  certain 
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demand  for  the  part,  then  the  part  may  become  a  carried  item.  An  Engineering  Facility  does  the 
research  to  get  the  new  parts. 

Maintenance  can  be  performed  without  the  TYCOM  approval.  As  the  maintenance 
proceeds,  man  hours  are  extended  up  to  the  point  where  the  repair  action  gets  stopped;  whether 
or  not  the  repair  gets  completed.  The  remarks  block  is  used  to  indicate  if  the  part  is  broken,  and 
codes  are  used  to  document  when  a  problem  is  discovered  and  the  reason  why  the  work  stopped. 

The  purpose  of  SAMMS  EMS  is  to  keep  the  vehicles  maintained  through  Preventive 
Maintenance  tracking  processes.  All  data  (Equipment  History  and  Equipment  Maintenance  data) 
for  the  vehicles  in  the  allowance  gets  entered  into  the  history  file.  When  the  history  has  been 
entered  and  completed  on  the  vehicle,  a  schedule  is  created  for  preventive  maintenance.  The 
vehicles  are  scheduled  regularly  to  go  in  for  preventive  maintenance. 

•  Equipment  Maintenance  and  Equipment  Operations  relationships; 

As  stated  in  section  4.0,  SAMMS  EMS  interacts  with  the  Equipment  Operations  System 
on  a  daily  basis.  Data  is  exported  from  the  EM  system  to  the  EO  system,  and  vice  versa.  The 
purpose  of  the  file  transfers  is  to  ensure  that  each  system  has  current  vehicle  information. 

Equipment  Maintenance  exports  the  following  data  to  Equipment  Operations:  USN, 
ECC,  Model,  and  PM  Schedule  for  the  vehicles.  Once  the,  Equipment  Operations  has  the  USN 
and  the  ECC  data,  then  dispatch  of  r  vehicles  can  occur.  Equipment  Operations  is  only  able  to 
dispatch  those  vehicles  for  which  it  has  current  information. 

Equipment  Operations  exports  the  following  data  to  Equipment  Maintenance:  Date  (in 
and  out),  if  vehicle  is  ready  for  dispatch  or  in  the  shop,  meter  readings  (in  and  out  -used  for 
continuous  mileage  tracking),  and  outshop  date. 

Micro  SNAP  HMDS  /  OMMS  does  not  have  the  Equipment  Operations  and  the 
Equipment  Dispatch  and  Licensing  functions,  which  must  exist  in  order  to  perform  data  transfer 
functions  between  the  Equipment  Maintenance  and  the  Equipment  Operations  systems. 

•  United  States  Navv  Registration  Number  (USN): 

On  Ship,  there  is  no  provision  for  handling  USN  numbered  equipment;  however,  there 
are  many  other  ways  to  identify  or  find  the  equipment.  Each  major  piece  of  equipment,  such  as  a 
fork  lift,  has  a  unique  Record  Identifier  Number  (RIN)  assigned  to  track  the  equipment.  Each 
peripheral  piece  of  equipment  also  has  a  unique  RIN.  The  RIN  is  the  primary  search  key  in  the 
Equipment  file.  If  the  MDS/OMMS  subsystem  were  to  be  used  for  tracking  USN’S,  there  would 
have  to  be  a  validation  team  (assigned  by  the  Concord  Weapon  Systems  people)  sent  to  the  site 
who  would  set  up  the  RIN’s.  The  USN  might  be  put  in  the  Valve  Mark  field,  or  it  could  possibly 
be  part  of  the  Equipment  System  Designator  (ESD).  The  data  would  also  have  to  be  added  to  the 
Ships  Configuration  and  Logistics  Support  Information  (SCLSI)  database  file  retained  by  SPCC. 
The  key  to  SAMMS  EMS  is  the  USN.  The  USN  is  the  identifier  for  a  particular  piece  of 
equipment  (vehicle). 
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Equipment  Code  (ECC  or  EC): 


In  SAMMS  EMS,  the  6-character  ECC  is  listed  as  a  number  to  identify  the  type  of 
equipment/vehicle.  This  number  can  be  a  duplicate,  if  a  vehicle  is  exactly  the  same  as  another 
vehicle.  It’s  used  along  with  the  USN  to  identify  the  equipment. 

The  ECC  number  is  not  listed  in  Micro  SNAP  II MDS/OMMS. 

•  Equipment  Identification  Code  (EIC): 

The  7-character  EIC  field  is  used  in  Micro  SNAP  II  MDS/OMMS  to  identify  the  system, 
subsystem,  equipment  category  in  that  system,  and  additional  definition  of  the  equipment  part. 
This  data  field  is  pre-filled  by  the  system  from  information  in  the  Ship’s  Equipment  File. 

The  EIC  is  not  used  in  SAMMS  EMS. 

•  Location: 

The  location  in  Micro  SNAP  II  MDS/OMMS  indicates  where  the  item  is  that  needs  to  be 
repaired.  It  is  a  four  part  field  made  up  of  the  compartment,  the  deck,  the  frame,  and  the  side. 

The  location  in  SAMMS  EMS  is  a  location/allowance  code  consisting  of  a  3  character 
field  used  to  indicate  where  the  unit  is,  i.e.,  the  code  CR1  might  represent  the  equipment 
allowance  in  Roosevelt  Roads  (camp). 

•  Unit  Identification  Codes  (UIC): 

Micro  SNAP  II  is  written  to  allow  for  multiple  UIC’s. 

SAMMS  EMS  documents  the  UIC  on  the  ERO.  Only  one  UIC  can  be  entered  on  an 
ERO.  NCB’s  and  other  special  units  each  have  a  unique  UIC. 

•  Functional  Description: 

The  functional  description  field  in  Micro  SNAP  II  MDS/OMMS  is  used  as  an  APL  level 
description  and  is  actually  a  repeat  of  the  APL  description. 

The  functional  description  field  in  SAMMS  EMS  is  the  name  of  the  actual  repair  being 
done,  i.e.,  replace  axle  gasket.  This  functional  description  is  the  same  as  the  work  description  on 
the  ERO.  The  functional  description  is  preceded  by  a  functional  code,  which  is  an  assigned  code 
for  the  functional  description  itself. 
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Technical  Manuals: 


Micro  SNAP  II MDS/OMMS  does  not  keep  track  of  technical  manuals;  however,  there  is 
a  separate  Technical  Publication  Library  System  (unrelated  to  the  SNAP  systems)  designed  by 
NCTAMS  LANT,  which  automates  a  facility’s  technical  publication  library  and  includes 
barcode  technology,  if  desired.  Currently,  the  2nd  Brigade  is  utilizing  this  library  system. 

Technical  Manuals  are  not  tracked  in  SAMMS  EMS.  The  mechanic  goes  to  the  technical 
library  to  get  the  information  to  put  on  the  1250  for  a  given  part  and  he  uses  this  information  to 
get  the  part  from  ARP  or  to  order  the  part  DTO. 

7.0  COSAL  SUPPORT/MAINTENANCE 


How  the  reporting  of  a  configuration  change  is  supported  and  how  a  ship  reports  the 
population  of  new  vehicles: 

The  COSAL  for  an  NMCB  would  probably  compare  to  the  Ships  Hull,  Mechanical, 
Ordnance  and  Electrical  COSAL  used  in  the  SNAP  system;  however,  there  are  big  differences  in 
the  way  that  he  NMCB’s  and  the  Ships  get  their  COSAL  support. 

In  Micro  SNAP  II  MDS/OMMS,  a  maintenance  action  causes  action  to  the  CQSAL. 

This  is  how  the  COSAL  is  run/setup.  The  Ship  reports  the  configuration  changes  and  the 
population  of  new  vehicles  to  SPCC  by  using  a  Configuration  Change  Report  4790/CK.  The 
ship  is  different  than  the  NMCB’s  because  the  Skipper  of  the  ship  has  to  send  papers  to  SPCC 
detailing  the  ships  configuration  change.  The  NMCB’s  don’t  have  to  do  this.  This  is  all  done  for 
the  NMCB’s  by  CESO  at  the  request  of  the  Equipment  Office. 

In  the  NMCB’s,  a  requirement  is  submitted  from  the  2nd  and  3rd  Brigade’s  Equipment 
Office  Program  Managers.  CESO’s  Construction,  Automotive  and  Specialized  Equipment 
Information  System  (CASEMIS)  and  the  2nd  and  3rd  NCB  Equipment  Offices  have  the 
equipment  on  record.  Based  on  file  changes,  the  managers  tell  CESO  to  generate  COSAL 
support  (new  COSAL).  CASEMIS  handles  the  configuration  reporting  (record  keeping)  of  the 
equipment.  CESO  initiates  the  COSAL  through  SPCC.  If  an  individual  item/part  in  an  APL 
needs  to  change,  CESO  prepares  a  form  1220,  and  mails  the  form  to  SPCC.  SPCC  performs  data 
entry  on  1220’s  to  change  the  APL  at  SPCC. 

CESE  COSAL  Maintenance 


The  methods  used  for  initial  outfitting  and  re-supply  of  parts  to  the  NCF  and  to  the  Naval  Ships 
are  different.  A  comparison  was  made  during  a  conference  at  the  20th  NCR  in  1987,  and  the 
differences  still  hold  true  to  today. 

•  FLSIP  and  like  shipboard  COSAL  methods: 

The  Fleet  Logistics  Support  Improvement  Program  (FLSIP)  COSAL  Program 
commences  with  a  very  minimal  (baseline)  initial  outfitting  storeroom  allowance,  and  through 
the  3M  reporting  process,  collects  usage  data,  computes  adjustments  based  on  models  and 
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forwards  reports  to  unit  supply  officers,  which  are  used  as  authorization  to  increase  or  decrease 
storeroom  allowances.  FLSIP  COSAL  changes  require  at  least  a  30  day  collection  of  usage  data, 
computation  and  reporting  back  to  supply  officers  before  storeroom  increases  can  be  ordered  and 
stocked.  Sixty  days  after  the  high  usage  occurs,  parts  could  be  on  the  shelf.  This  process 
minimizes  unit  supply  officer  local  management  decision  making  and  flexibility  because  the 
computer  tells  them  what  to  do. 

The  FLSIP  method  would  not  accomplish  what  the  NCF  needs  because  in  the  NCF, 
Supply  is  notified  immediately  and  parts  are  ordered  right  away.  Keeping  shipboard  COSAL’ s 
current  with  a  ships  actual  equipment  configuration  has  always  been  a  difficult  process.  The 
opinion  is  that  the  use  of  a  mechanized  COSAL  maintenance  program  such  as  FLSIP  may  not  be 
a  good  idea  for  the  NCF. 

NAVFAC  and  CESO  have  not  gone  to  this  FLSIP  method.  The  Equipment  side  of  the 
Second  and  Third  Brigades  have  not  gone  to  FLSIP  either.  They  prefer  a  manual  review  of 
consumption  data  and  adjustments  in  accordance  with  special  criteria  that  are  not  provided  for  in 
the  standard  FLSIP  program.  That  criteria  is  initial  outfitting  support  of  new,  or  like-new 
equipment  in  a  60  day  wartime  contingency.  Allowance  Change  Requests  can  be  submitted  by 
the  using  battalion  but  the  decision  criteria  remains  the  same. 

.  NAVFAC  CESE  COSAL  method: 

The  CESE  COSAL  provides  a  complete  list  of  initial  outfitting  parts  authorized  by 
NAVFACENGCOM  maintenance  policy  to  support  new  or  like-new  construction,  automotive, 
material-handling,  and  specialized  equipment.  Each  camp  site  receives  two  CESE  COBALs;  one 
for  organic  and  one  for  augment,  which  are  updated  during  each  deployment  rotation  (about 
every  7  months). 

The  NAVFAC  CESE  COSAL  Program  commences  with  an  initial  outfitting  storeroom 
allowance  of  mission  essential  parts  (starters,  alternators,  water  pumps,  tires,  etc.)  plus  required 
maintenance  parts  (filter  elements,  spark  plugs,  etc.)  for  support  of  60  day  (1200  hours) 
contingency  or  mobilization  operation,  without  re-supply. 

If  one  site  has  a  high  usage,  the  allowance  doesn’t  get  changed  for  everyone.  Orders 
must  be  made  by  the  supply  office  to  supply  the  parts.  One  site  doesn’t  justify  changing  the 
APL,  as  would  happen  in  the  FLSIP  method. 

Changes  to  a  NAVFAC  CESE  initial  outfitting  APL  affects  the  total  population  for  that 
APL  regardless  of  age,  location,  deployment  or  storage  (PWRMS,  Readyline,  etc.)  status  and 
results  in  automatic  storeroom  allowance  increases  or  decreases  for  all  Nary  units  being 
supported. 

The  NAVFAC  CESE  COSAL  Program  assumes  unit  supply  officers  will  solicit  planned 
requirement  recommendations  from  the  maintenance  supervisor,  determine  items  to  be  ordered 
and  stocked  in  anticipation  of  need,  maintain  COSAL  allowance  on  an  “issue-one/order-one”  or 
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Selective  Item  Management  (SIM)  basis,  and  review  the  historical  demand  file  to  determine  Not 
Carried  or  Part  Numbered  items  to  stock. 

The  result  is  that  the  current  NAVFAC  CESE  COSAL  Program  starts  all  units  off  with  a 
well-stocked  initial  outfitting  storeroom  allowance  and  permits  the  maximum  amount  of  local 
management  decision  making  regarding  adjustments  to  take  place  without  delay  for  usage 
reporting  and  computations. 

•  Overall  assessment  of  the  COSAL  methods: 


The  FLSIP  method  is  designed  for  lifetime  operation  of  the  ship  or  activity.  FLSIP  is  a 
system  that  has  a  different  mission  than  that  of  the  CESE  COSAL  for  the  NCF.  FLSIP 
continually  gives  you  changes  and  keeps  you  moving  in  the  proper  direction  for  the  life  of  the 
ship.  CESE  in  the  NCF  is  maintained  in  a  new  (or  like  new)  condition  for 
mobilization/deployment  to  a  60  day/ 1200  hour  operation  and  requires  a  mobile  repair  parts 
storeroom/COSAL. 

8.0  CONCLUSION: 

This  evaluation  provided  an  overview  of  many  major  functional  differences  between 
MDS/OMMS  and  SAMMS  EMS.  These  two  systems  are  developed  according  to  different, 
instructions.  It  is  improbable  that  MDS/OMMS,  as  it  is  currently  designed,  could  be  utilized  in 
the  NCB  environment.  Either  MDS/OMMS  will  need  to  be  changed  to  adapt  to  the  Seabee 
operational  environment  and  methods,  or  the  Seabee  environment  will  need  to  make  changes  in 
the  way  operations  are  performed  in  order  to  utilize  MDS/OMMS  to  do  business.  A  major 
detailed  analysis  would  be  required  to  determine  the  additions  and  modifications  that  would  be 
required  to  properly  utilize  MDS/OMMS. 

9.0  ALTERNATIVE: 

If  standardization  is  the  intention,  the  shorebased  PWMA  Transportation  system  may  be 
more  appropriate  for  use  in  the  NCF. 

The  Public  Works  Management  Activity  (PWMA)  Transportation  System  managed  by 
the  PWMA  Division  at  FACSO,  Port  Hueneme,  more  closely  resembles  SAMMS  EMS  than 
MDS/OMMS.  The  Transportation  system  is  a  civilian  shorebased  system  developed  utilizing 
Micro  Focus  COBOL.  It  processes  maintenance  schedules  for  equipment,  records  maintenance, 
tracks  the  time  against  job  orders,  issues  trip  tickets,  and  keeps  track  of  operators  times,  among 
many  other  features.  The  Shop  Repair  Order  (SRO)  function  basically  resembles  the  EMS 
Equipment  Repair  Order  (ERO)  function.  The  SRO  is  keyed  on  the  USN  and  its  purpose  is  to 
track  time,  labor,  and  material,  and  it  can  be  deferred  if  parts  aren’t  available. 

The  PWMA  Transportation  system  provides  management  reports  such  as  financial,  job 
order,  and  cost  category  reports,  and  NAVFAC  required  utilization  and  exception  reports  (i.e., 
accident  exception  report).  Although  the  look  of  PWMA  Transportation  system  is  quite  different 
than  the  SAMMS  Equipment  Maintenance  System,  it  basically  tracks  the  same  work.  The 
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system  is  Equipment  Maintenance  (EM)  and  Equipment  Operations  (EO)  all  in  one. 
Additionally,  it  contains  a  Fuel  interface  module  which  is  tailored  to  a  particular  unit. 
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SCLSIS  DATA  FLOW  FOR  MANUAL  OPERATIONAL  SHIPS 


SCLSIS  DATA  FLOW  DURING  AN  ILO 


Figure  3 
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APPENDIX  F 


Related  costs/REQUIREMENTS  FOR  CDMD-OA 


CDMD-OA: 

Cost  per  Unit  Identification  Code  per  year 

View  only  -  $2,000  per  UIC  per  year 

Edit  capability  -  $4,000  per  UIC  per  year 

Software  Requirements: 

Oracle  SQLnet  (ver  1.0,  2.1, 
2.2,  2.3) 

Windows  (ver  3.1,  NT,  95,  98) 

CITRIX  Web  Client 

MicroSnap  OMMS 

Downloadable  from  CDMD  web  site 

$$$  (unknown) 

Hardware  Requirements: 


486/75  CPU 
VGA  Monitor 
3MB  RAM  memory 
NIC 

800  MB  Hard  drive 


UIC  established 


CDM  established 

CBCHUE  sending  personnel  to  CDM 

training  FY01 
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NAVICP-M 

Validate  configuration  of  each  UIC 

Perform  site  validations 

Load  adds/changes/deletes  in  WSF 

SPAWAR  CHESAPEAKE 
Licensing  fee 

Initialize  MicroSnap  OMMS 
Life  cycle  cost 


Reimbursable  effort  (travel  and  labor) 


$1 38K  for  57  NCF  sites 

$1 .00  per  record,  minimum  $500.00 

$$$  (unknown) 

T ravel  costs 


Costs  related  to  MicroSnap  OMMS 

} 

x 


Costs  related  to  Configuration  Data  Manager  for  NCF 
NAVICP-M 

Based  on  number  of  UlCs  Ex.  $1 8,000  for  24  UlCs 


CBCHUE 

T raining  course  $$$  T ravel  costs 

Dedicated  personnel  $$$  per  manyear 


Costs  related  to  Automated  Shore  Interface 
RADCOM  -  automated  updates  $$$  (unknown) 

SPAWAR  -  floppies  None 


F-2 


APPENDIX  G 


MicroSNAP  OMMS  A1  Record  Compared  to  MicroSNAP  MOSS 

(A1  Record  Comparison.doc  /  3-22-00) 


A1  Data  Element  Name 

Pos 

Mandatory* 
see  below 

In 

MOSS 

MOSS  Comments  / 
Field  Names 

Record  Type 

1-2 

Yes 

No 

Action  Code 

3-3 

Yes 

No 

Unit  Identification  Code 

4-8 

Yes 

No 

In  SMS 

Work  Center 

9-12 

No 

Yes 

Mandatory  -  Primary 

Work  Center  in 
museraccess.cprimwc 
(4  pos) 

Job  Sequence  Number 

13-16 

No 

No 

ERO’s  only  -  in 
meqptmnt.cjobseqno  (4 
J?os) _ 

Page  Number 

17-20 

No 

No 

RIN  (Record  Identification  Number) 

21-25 

Yes 

No 

MCC  (Service  Importance  Code) 

26-26 

Yes 

No 

Log.  Support  Status  Code 

27-28 

No 

No 

Blank 

29-32 

Military  Essentiality  Code 

33-33 

Yes 

No 

In  SMS 

CAGE  (Component/Mission) 

34-38 

No 

Yes 

Mandatory  -  in 
mequ.ccage  (5  pos) 

APL/CID/RIC  Component  ID 

39-49 

Yes 

Not  mandatory  -  in 
mequ.capl(11  pos) 

EIC  (Equipment  Ident.  Code) 

50-56 

Yes 

No 

Application  Code  (Parent  APL) 

57-67 

No 

No 

MOSS  has  3  APL  fields 
in  mequ  (capl,  capl2, 
capl3) 

Qty  per  Application 

68-73 

Yes  *1 

? 

Default  to  1? 

Equipment  Serial  Number 

74-88 

Yes  *2 

Yes 

Mandatory  -  in 
mequ.cequserialno  (19 
_ROs) _ 

Parent  Eqpt  Serial  Number 

89-103 

No 

No 

Data  origin.A/alid.  Code  (DO/VC) 

104-105 

Yes 

No 

Service  Application  Description 

106-160 

No 

No 

Service  Application  Code 

161-170 

Yes 

No 

Location 

171-182 

No 

Yes 

Mandatory-  in 
mequ.cequlocation 
(6  pos) 

VM/ESN  or  PRID 

183-197 

Yes  *3 

No 
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A1  Data  Element  Name 

Pos 

Mandatory* 
see  below 

In 

MOSS 

MOSS  Comments  / 
Field  Names 

Space  Work  Center  (WCRC) 

198-201 

No 

Yes 

Not  mandatory  -  in 
mequ.cequwcrc 
(4  pos) 

Maintenance  Work  Center  (WCRE) 

202-205 

Yes  *4 

Yes 

Mandatory  -  in 
mequ.cequwcre 
(4  pos) 

HSC  (+  6  other  fields) 

206-217 

Yes 

No 

Subcateqory  Code  (SCAT) 

218-224 

Yes  *5 

No 

Installation  Status  Code  (ISC) 

225-225 

Yes 

No 

Valid  Source/Action  Code 

226-227 

No 

No 

Equipment  ID  Number  (EIN) 

228-253 

No 

No 

Cateqory  Code 

254-254 

No 

No 

Selected  Equipment  Indicator 

255-255 

No 

No 

Reason  Not  Validated 

256-256 

No 

No 

Equipment  Functional  Description 

257-304 

Yes 

Yes 

Mandatory  -  prefilled 
from  EC  Number  -  in 
mequ.cequlongdesc  (40 
POS) 

Equipment/System  Designator 

305-319 

Yes 

No 

Configuration  Reporting  Activity 

320-328 

No 

Yes 

Not  Modifiable  -  in 
mequ.ccactivityuic 
(6  pos) 

Configuration  Report  Initials 

329-332 

No 

Yes 

Not  Modifiable  -  in 
mequ.clastmodby 
(3  pos) 

Configuration  Report  Date 

333-338 

No 

Yes 

Not  Modifiable  -  in 
mequ.dlastmoddte 
(8  pos) 

Blank 

339-400 

*1  =  Must  be  equal  to  1  if  AEL  COL  NBR  is  assigned.  Cannot  be  greater  than  1  if  Serial  Number  or 
PRID  is  assigned. 


*2  =  Blank  if  quantity  per  application  is  greater  than  1 .  Required  if  quantity  equals  1  and  PRID  is 
blank. 

*3  =  Mandatory  entry  if  quantity  per  application  equals  1  and  serial  number  is  blank. 

*4  =  Required  at  equipment  add  time  interactively  or  via  ASI  verify  bulk  input. 

*5  =  Mandatory  if  the  configuration  item  is  electronics  test  equipment. 
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APPENDIX  H 


Point  Paper  on  Software  Construction  Preparation 
Ideas  extracted  from  the  book 
Code  Complete  by  Steve  McConnell1 

Steps  of  Software  Construction 

Building  software  is  a  lot  like  building  a  house  or  a  skyscraper.  The  amount  of 
preparation  done  before  construction  begins  depends  on  what  you  want  to  build.  The 
amount  of  time  spent  on  each  of  the  following  construction  steps  depends  on  the  size  of 
the  project.  The  smaller  the  project  the  less  time  needed  in  each  step. 

1 .  Problem  Definition  -  System  Specification 

2.  Requirements 

3.  Architectural  Design 

4.  Detailed  Design 

5.  Coding  and  Debugging 

6.  Unit  Test 

7.  System  Test 

8.  Maintenance 

The  quality  of  the  finished  product  depends  on  the  quality  of  the  preparation. 

Much  of  the  success  or  failure  of  a  project  is  already  determined  before  construction 
begins. 

Problem  Definition 

The  first  step  is  to  define  the  problem.  “We  are  cold  at  night  and  get  wet  when  it  rains. 
We  want  to  keep  all  of  our  stuff  safe.  We  need  a  place  to  sustain  our  lives,  work  and 
play  (using  the  latest  tools)  safely  and  comfortably.”  That  is  a  problem  statement  that 
constructing  a  house  will  solve.  What  is  the  problem  the  SUL  is  trying  to  solve? 

Requirements 

The  next  step  is  requirements.  “We  want  a  two  story  2300  square  ft.  house  with  a  three 
car  attached  garage  (wired  for  sound,  TV  and  high  power  tools)  and  a  stucco  (walls) 
and  tile  (roof)  exterior.  Three  bedrooms  and  three  bathrooms  with  a  master  bath  and 
walk-in  closet  attached  to  the  master  bedroom.  A  sound  insulated  surround  sound  and 
Internet  (cable  modem)  ready  den  with  room  for  a  60”  flat  screen  display.  And  a 
gourmet  kitchen  with  standard  (not  custom)  equipment  (range,  oven,  refrigerator,  etc.)” 
These  requirements  specifically  state  what  features  are  required  and  give  boundaries 


1  Code  Complete:  A  Practical  Handbook  of  Software  Construction,  Microsoft  Press,  Redmond, 
Washington,  1993,  Chaps.  1-3  “Laying  the  Foundation”,  pp.  1-52 
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for  the  architect  to  follow  when  she  designs  (draws  blueprints)  the  house.  What  logistic 
features  does  the  Small  Unit  need  to  complete  its  tasks? 

The  eventual  occupant  of  the  house  best  answers  the  questions  these  first  two  steps 
ask. 

Stable  requirements  are  the  myth  and  Holy  Grail  of  software  development.  The  more 
you  work  on  a  project  the  better  you  understand  it  and  your  needs.  Therefore,  it  is 
inevitable  that  you  will  want  to  add  or  change  features.  An  IBM  study  reveled  that  the 
average  project  experiences  a  25%  change  in  requirements  during  development. 

So  how  do  we  deal  with  changing  requirements? 

1)  We  make  sure  that  the  requirements  are  of  high  quality.  Requirements  can  be 
checked  for  content,  completeness  and  quality  using  Steve  McConnell’s 
requirements  checklist2. 

2)  Make  sure  everyone  knows  the  cost  of  requirements  changes.  For  example  to  move 
a  load  bearing  wall  6  inches,  after  construction  requires  redesign  and  rebuild.  The 
load  the  wall  is  holding  is  temporarily  supported  while  the  old  wall  is  removed  and 
the  new  one  installed.  The  high  cost  comes  not  so  much  from  the  materials  but  the 
time  and  labor  involved. 

3)  Set  up  a  change  control  procedure.  For  example  setting  specific  times  or  stages 
when  all  new  requirements  will  be  addressed.  This  allows  the  builder  time  to  deal 
with  either  constructing  to  the  plan  or  laying  out  new  plans. 

4)  Use  development  approaches  that  accommodate  changes.  You  can  use  the 
following  two  approaches  together  or  separately. 

a)  Prototyping  the  software  with  a  small  inexpensive  team  to  explore  the 
requirements  before  the  forces  are  sent  in  to  build. 

b)  Evolutionary  development  where  short  development  cycles  build  a  little  then 
users  provide  comments  around  and  around. 

Architecture 

At  this  point  in  software  development  of  complex  systems,  a  professional  software 
architect  should  probably  be  consulted.  Just  as  the  home  architect  translates  the  needs 
and  wants  of  the  future  occupants  into  a  comprehensive  plan  that  uses  the  latest  tools 
and  techniques,  so  to  the  software  architect.  High  quality  architecture  will  discuss 
modules3  in  the  system,  information  in  each  module  and  rationales  for  including  and 
excluding  all  possible  design  alternatives.  The  architecture  should  be  a  conceptual 
whole,  fit  the  problem  and  meet  the  requirements.  It  should  state  its  objectives  clearly, 
for  example:  is  the  goal  to  be  as  flexible  to  change  as  possible  or  high-speed 
performance?  Each  may  do  the  same  thing  but  in  entirely  different  ways.  It  should  be 


2  McConnell,  pp.33-34  (I  am  also  searching  for  more  on  this  subject  (not  a  moron) ) 

3  “A  module  is  a  collection  of  routines  that  work  together  to  perform  a  high  level  function...”, 
McConnell,  p.36 
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as  machine  and  language  independent  as  possible.  It  should  identify  risks  and  steps  to 
minimize  those  risks.  Finally,  it  should  be  easy  to  understand. 

Program  organization 

The  architecture  should  specify  the  system  in  broad  terms  as  well  as  the  major  modules 
in  the  program.  This  should  show  the  builder  how  the  modules  work  together  and  that 
alternatives  were  considered  but  not  chosen  for  particular  reasons.  Each  feature  should 
be  covered  by  at  least  one  module  and  each  module  should  be  as  independent  as 
possible. 

Change  Strategy 

The  architecture  should  describe  a  strategy  for  handling  changes  clearly.  It  should 
show  that  a  particular  change  has  been  anticipated  and  that  it  can  be  dealt  with  in  a 
particular  fashion. 

Buy-vs-build  decisions 

The  architecture  should  specify  what  software  is  to  be  reused  and  how  it  will  be  made  to 
conform  to  the  architecture. 

Major  data  structures 

The  architecture  should  describe  the  major  files,  tables  and  data  structures  to  be  used. 
It  should  specify  the  organization  and  contents  of  any  databases  used. 

Key  Algorithms  and  Major  Objects 

If  the  architecture  depends  on  specific  algorithms  or  objects,  it  should  specify  which 
ones  should  be  used  and  the  reasons  why  particular  ones  were  chosen. 

Generic  Functionality 

Users  interface,  input/output,  memory  management  and  string  storage  should  all  be 
addressed  in  the  architecture  by  estimating  or  describing  the  functionality. 

Error  Processing 

The  architecture  should  define  the  strategy  for  handling  errors,  when  to  catch  them,  how 
to  avoid  them  and  when  to  let  the  user  know. 

Robustness4 

The  architecture  should  clearly  indicate  what  level  of  over-engineering,  assertions5  and 
fault  tolerance  is  expected. 

Performance 

The  architecture  should  address  speed  and  memory  goals.  It  should  provide  estimates 
and  explain  why  the  goals  are  achievable. 


4  “Robustness  is  the  ability  of  a  system  to  continue  to  run  after  it  detects  an  error.”,  McConnell,  p.  41 

5  “An  assertion  is  an  executable  statement  placed  in  the  code  that  allows  the  code  to  check  itself  as 
it  runs.  When  an  assertion  is  true,  that  means  everything  is  operating  as  expected.  When  it  is  false,  that 
means  it  has  detected  ...  [something  unexpected  and]  ‘asserts’  that  it  found  an  error  [in  the  code]., 
McConnell,  p41 
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Let  the  code  construction  begin. 

The  amount  of  time  spent  on  problem  definition,  requirement  analysis,  and  software 
architecture  varies  with  the  needs  of  the  project.  “Generally  a  well-run  project  devotes 
20  to  30  percent  of  its  schedule  and  effort  to  planning,  requirements  and  architecture. 
The  20  to  30  percent  doesn’t  include  time  for  detailed  design  -  that’s  part  of 
construction.”6 

Detail  design 

The  detail  design  involves  choosing  programming  languages  and  programming 
conventions.  Programming  conventions  include  variable  names,  routine  names, 
formatting  conventions  and  commenting  conventions. 


6  McConnel,  p50 
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Email  from  CAPT  King  dated  05  Oct  2000 

— — Original  Message - 

From:  King,  Dan  [mailto:King.Dan@hq.navy.mil] 

Sent:  Thursday,  October  05,  2000  8:56  AM 
To:  3NCB  N01  CAPT  SHEAR  (E-mail) 

Cc:  Alvin  Kuehn;  C  Grau;  David  Balk;  'Hughes,  John';  James  McConnell; 

JIM  COWELL;  Jonathan  Miller;  Kenneth  Pieczonka;  Lunsford,  Katy  (E-mail); 
Michael  Hickinbotham;  W  MCKERALL;  William  Hargrove;  '3NCB  N6  LCDR 
STEVENSON'  (E-mail);  Plockmeyer  CAPT  (E-mail);  Lawless,  Matt  J;  Chase 
Alan  L  (CBCPH)  (E-mail);  Catherine_D_Alexander  (E-mail);  Don  Curtis 
(E-mail) 

Subject:  C4I  QMB  Tasking  for  NCF  Logistics  IT  Systems 


Sir, 

The  purpose  of  this  e-mail  is  to  better  define  the  tasking  of  the  C4I  QMB  regarding  the 
information  systems  supporting  NCF  Logistics. 

1.  Background:  As  briefed  and  discussed  last  month  by  the  LOG  QMB,  the  NCF  logistics 
information  systems  are  centered  around  two  main  sets  of  capability: 

a.  TOA  Management:  To  manage  NCF  TOAs  both  on  a  force-wide  basis  and  at  the 
operation  unit  level. 

b.  Operational  Logistics:  To  perform  supply  management  functions  integrated  with  the 
maintenance  and  spare  parts  systems.  Included  as  part  of  this  Operational  Logistics 
system  would  be  a  integrated  maintenance  system  for  units  to  manage  their 
CESE/TOA  maintenance  programs. 

SUPMIS  is  the  current  War  Reserve  Material  TOA  Management  system;  CAPT  Plockmeyer 
demonstrated  how  Maximo  could  be  used  to  perform  this  function  on  force  wide  basis.. 
MicroSNAP  is  the  current  Operational  Logistics  system,  but  has  not  been  fully  implemented  and 
thus  does  not  have  full  functionality.  The  NCF  CESE  maintenance  system  is  not  integrated  with 
MicroSNAP  at  this  time,  although  some  development  is  underway  to  create  a  MOSS-OMMs 
link.  We  also  discussed  the  fact  that  eventually  NAVSUP  will  migrate  the  Navy  operational 
supply  system  from  SNAP/MicroSNAP  system  to  a  yet  to  be  defined  system,  possibly  R-Supply 
or  a  NAVSUP  ERP  solution.  No  timeline  has  yet  been  set  for  this  migration.  Similarly,  it  was 
discussed  that  the  Navy  3M  system  may  migrate  to  another  maintenance  system  for  the  future. 
However,  this  migration  was  not  confirmed  as  a  definite  plan  and  no  timeline  was  given  for  any 
migration,  should  it  occur. 
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Based  on  this,  the  overall  strategy  for  improving  the  NCF  Logistics  system  was  to  take  some 
near  term  actions  to  improve  functionality  (i.e.  "stop  the  bleeding")  of  the  two  main  NCF 
logistics  systems  until  the  future  plans  of  the  Navy  supply  and  maintenance  systems  were 
known.  Ultimately,  the  NCF  would  migrate  to  these  future  Navy  systems. 

2.  Original  C4I QMB  Proposal:  When  the  C4I QMB  and  the  LOG  QMB  met  last  month,  the 
C4I  QMB  proposed  studying  whether  or  not  MicroSNAP  could  be  enhanced  to  perform  the  force 
level  TOA  Management  functions  and  whether  Maximo  could  be  enhanced  to  perform  some  of 
the  supply  functions  of  Microsnap.  Based  on  this  review,  it  would  then  be  determined  whether 
to  program  MicroSNAP  or  Maximo  to  do  the  NCF  TOA  Management  function. 

3.  Revised  LOG  QMB  Proposal:  The  LOG  QMB  would  like  to  change  the  direction  of  the  C4I 
QMB  tasking.  Rather  than  study  whether  or  not  Maximo  or  MicroSNAP  could  be  enhanced  to 
perform  the  functions  of  the  other,  the  LOG  QMB  would  like  the  C4I  QMB  to  focus  on  assessing 
whether  or  not  the  development  of  a  interim  solution  can  be  accomplished  in  a  timely  and  cost 
effective  manner.  Specifically  the  direction  that  the  LOG  QMB  would  like  to  pursue  is 

a.  Developing  Force  wide  TOA  management  capability  into  MAXIMO. 

b.  Enhancing/integrating  MicroSNAP  to  provide  improved,  unit  level  TOA  management 
capability 

c.  To  hold  off  on  the  3M  system  migration  until  it  is  clear  what  the  NAVSEA  plan  is  for 
moving  to  an  Enterprise  Resource  Planning  (ERP)  maintenance  solution.  Once  that  is 
clear,  the  Maximo  vs.  NAVSEA  ERP  alternative  can  be  assessed  against  each  other. 

4.  Proposed  C4I  QMB  Tasking:  If  we  take  this  approach,  the  C4I  QMB  tasking  would  need  to 
change  from  studying  Maximo  and  MicroSNAP  to  developing  an  integrated  plan  (including 
costs  and  timelines)  to  accomplish  the  following  goals: 

4.1  Review  the  Systems  Requirement  Document  produced  by  SPAWARS  as  well  as  the  cost 
estimate  and  timeline  for  enhancing  the  capability  of  MicroSNAP  to  manage  NCF  TOAs  at  the 
local,  unit  level.  This  review  should  assess  whether  it  will  be  feasible  and  cost  effective  to 
accomplish  the  following  subgoals: 

a.  Modify  the  Weapons  System  File  to  accommodate  the  hierarchical  structure  of  an 
NCF  TOA 

b.  Develop  local,  field  level  TO  A/inventory  management  capability  for  the  Seabee 
Camps/CBCs 

c.  Implement  Configuration  Management  through  the  use  of  the  Weapons  System  File 

If  feasible,  cost  effective,  and  timely,  the  C4I  QMB  should  develop  a  plan  for  implementing 
these  MicroSNAP  enhancements.  If  not  feasible  due  to  excessive  cost  or  development  time, 
advise  the  LOG  QMB  if  any  other  options  exist  to  enhance  unit  level,  local  TOA  management 
capability  that  would  be  both  cost  effective  and  timely. 
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4.2  Determine  what  additional  information  systems  development  or  process  is  required  to 
implement  the  MOSS-OMMS  link  to  capture  spare  parts  usage  under  the  current  maintenance 
system.  Develop  a  cost  estimate  and  timeline  to  implement. 

4.3  Develop  a  cost  estimate  and  timeline  to  implement  force  level  TOA  management  capability 
into  Maximo. 

4.4  Develop  a  plan  to  create  single  source  of  NCF  TOA  data,  accessible  by  Maximo,  for  force 
level  TOA  management  processing/analysis.  This  plan  should  include  both  the  architecture  of 
the  data  source,  the  process  to  migrate  the  existing  data  to  this  Master  TOA  data  source,  as  well 
as  the  cost  and  timeline  to  implement. 

4.5  Determine  what  additional  information  systems  development  is  required  to  create  the 
interfaces  necessary  to  link  Maximo  and  MicroSNAP  so  that  TOA  configurations  and  TOA 
inventories  and  the  Master  TOA  Data  stay  syncronized.  Develop  a  cost  estimate  and  timeline  to 
implement  these  links. 

4.6  Develop  a  recommendation  regarding  the  organizational  structure/project  management, 
subject  matter  expert  (SME)  support/resources  required  to  direct/manage  the  Logistics  IT 
improvement  effort. 

This  goal  of  this  proposed  change  is  to  position  the  NCF  to  be  able  to  initiate  the  interim  solution 
as  quickly  as  possible.  This  approach  would  allow  the  NCF  to  make  near  term  progress  on 
improving  capability  at  both  the  Force  and  unit  levels,  while  not  precluding  the  eventual 
migration  to  the  long  range  Navy  Logistics  solution.  The  attached  set  of  slides  illustrates  the 
current,  proposed  near  term,  and  likely  long  term  phases  of  the  IT  improvements  for  the  NCF. 

5.  Maintenance  System  At  the  joint  LOG  &  C4I QMB,  there  were  different  proposals  as  to  how 
to  handle  the  Maintenance  system.  The  option  was  to  implement  the  3M  capability  of 
MicroSNAP  or  whether  to  use  the  maintenance  module/capability  of  Maximo.  The  proposal 
detailed  above  does  not  resolve  that  issue.  On  one  hand,  it  was  felt  that  Maximo  had  better 
capability  and  that  a  3M  solution  was  not  the  best  fit  for  the  NCF.  On  the  other  hand,  the 
direction  from  N4  is  migrate  to  standard  Navy  systems,  with  3M  being  the  Navy  shipboard 
maintenance  standard.  Thus  the  concern  was  that  a  Maximo  developed  maintenance  system  may 
not  be  in  keeping  with  the  direction  to  move  to  standard  Navy  systems,  even  though  Maximo  is  a 
NAVFAC,  shore  installation  standard  Navy  system.  Subsequent  discussions  with  NAVSEA 
indicate  that  they  are  going  to  migrate  from  3M  to  a  COTS  based,  enterprise  level  (ERP— 
enterprise  resource  planning)  maintenance  package  in  the  next  year  or  two.  The 
recommendation  would  be  to  continue  to  research  the  Maintenance  portion  of  the  NCF  Logistics 
system,  so  that  whatever  system  we  choose  to  implement  positions  the  NCF  well  for  migration  to 
this  long  term  Maintenance  solution.  According  to  the  NAVSEA  IT  rep,  if  they  goes  to  this  ERP 
based  maintenance  system,  the  Navy  will  use  the  maintenance  processes  of  that  system,  even  if 
that  means  that  it  departs  from  the  current  3M  system.  However,  NAVSEA  did  state  that  much 
of  the  same  approach/philosophy  of  3M  will  be  retained  (reliability  based  maintenance,  the 
maintenance  requirements  and  parts/tools  listings  currently  captured  on  the  3M  cards  will  be 
converted  into  computerized  work  orders  in  the  new  system).  Depending  on  how  fast  this  ERP 
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system  might  be  fielded,  it  may  make  sense  to  hold  off  on  implementing  3M  and  just  make  the 
transition  to  the  ERP  type  system.  In  the  interim,  the  data  needed  to  make  either  system  work 
could  be  developed  (maintenance  requirements,  parts  lists,  ect.)  since  this  will  be  a  significant 
effort  unto  itself.  This  information  can  be  reused  under  any  system  we  migrate  to.  Due  to  the 
uncertainty  of  the  maintenance  system  migration,  recommend  we  research  this  further  before 
taking  any  specific  actions  on  implementing  3M  in  any  form. 

Request  your  thoughts  on  changing  the  C4I  QMB  direction  as  detailed  above.  Is  the  C4I QMB 
willing  to  take  this  approach  and  tackle  the  taskings  of  paragraph  4  above?  The  goal  would  be  to 
report  back  to  the  LOG  QMB  at  the  earliest  possible  date,  so  that  the  total  funding  requirement 
and  timeline  is  known.  In  PR-01,  funds  were  programmed  for  NCF  IT  modernization.  These 
funds  were  generally  intended  for  hardware  replacements,  but  could  be  used  for 
software/systems  development  if  it  was  felt  to  be  a  more  urgent  priority.  The  LOG  QMB  would 
need  to  make  this  case  to  the  NCF  ESG.  The  sooner  we  know  if  an  interim  solution  is  feasible 
and  its  cost,  the  sooner  we  can  make  that  funding  call  and  begin  implementation. 

Very  Resp, 

Dan  King 

«NCF  IT  System  Proposal.ppt» 

CDR  Dan  King 
OPNAV  N446 
Seabee  Programs 
(703)  604-9945 
DSN  664-9945 
kinq.dan@hq.navy.mil 
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APPENDIX  K 


Report  on  taskings  directed  in  memo  from  Capt.  King  to  Capt.  Shear, 

“C4I  QMB 

TASKING  FOR  NCF  LOGISTICS  IT  SYSTEMS”  dtd  5  Oct  00.  See  Attachment  1. 

Tasking  4.1  Review  the  Systems  Requirement  Statement. 

Tasking  4.1a  Weapon  Systems  File  (WSF)  and  4.1c  Configuration  Management 

1 .  The  WSF  structure  can  not  be  modified  without  an  extended  timeframe  and 
unknown  financial  burden.  Representatives  from  NAVICP  stated  they  were  unaware 
of  any  modifications  to  the  WSF  structure.  Currently  no  NCF  data  resides  within  the 
WSF. 

2.  The  CDM  must  be  established.  The  CDM  is  the  NAVSEA  agent  for  maintaining 
configuration  and  associated  logistics  support  for  an  activity  represented  in  the  Ship 
Configuration  and  Logistic  Support  Information  (SCLSI)  database.  Only  the 
cognizant  CDM  can  input  data  into  the  SCLSI  database.  CDM  responsibilities 
include: 

a.  Process  configuration  changes  initiated  by  the  activity  or  the  In-Service 
Engineering  Agent,  Ship’s  Equipment  File  corrections,  and  logistics  support  data 
into  the  SCLSI  database. 

b.  Initiate  configuration  changes  to  correct  erroneous  or  missing  data  in  the  SCLSI 
database.  The  file  corrections  ultimately  update  MicroSnap  and  shore  databases 
via  the  Automated  Shore  Interface  (ASI). 

c.  Compare  the  activity’s  MicroSnap  database  with  the  SCLSI  database  and 
reconcile  differences  before  the  start  of  ILO  operations. 

d.  Process  ILO/Naval  Supervising  Activity  (NSA)-initiated  equipment  file  corrections 
and  logistic  support  data  into  the  SCLSI  database  so  it  accurately  reflects  the 
activity’s  equipment  and  logistics  support  databases. 

e.  Perform  baseline  validations.  Providing  validation  aids  to  SCLSIS  Validations 
Teams. 

3.  In  order  to  populate  the  WSF,  the  CDM  must  establish  accurate  electronic  data 
reflecting  the  current  TOA  configuration.  This  must  be  completed  for  each  unique 
Unit  Identification  Code  (UIC)  specific  TOA,  i.e.,  Camp  Moscrip,  Camp  Mitchell, 
HomeportTOAs. 

4.  Once  the  data  has  been  obtained,  NAVICP  performs  a  site  validation  of  each  unique 
TOA.  Once  this  is  complete,  NAVICP  loads  adds/changes/deletes  into  the  WSF  and 
generates  spare  part  and  allowance  data  in  the  form  of  COSALs. 

CBCHUE  stated  Ruben  Frutos  could  accomplish  the  task  after  training  is 
completed  -  December  2000.  The  alternative  will  be  to  fund  NAVICP  to  be  the 
CDM.  NAVICP  efforts  to  establish  NCF  data  in  the  WSF  are  cost  reimbursable. 
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Costs  for  NAVICP  to  maintain  the  WSF  data  for  the  NCF  are  based  on  number  of 
UlCs  -  estimated  $1 8,000  per  year  for  24  UlCs. 

5.  SPAWAR  Chesapeake  installs  and  initializes  MicroSnap  OMMS  at  each  UIC 
location.  The  cost  for  the  initialization  is  $1 .00  per  Allowance  Part  List/Allowance 
Equipage  List  (APL/AEL)  record,  with  a  minimum  cost  of  $500  per  UIC,  plus  the 
travel  expenses  for  the  SPAWAR  personnel.  This  does  not  include  the  licensing 
fee(s)  for  the  MicroSnap  OMMS  application. 

How  many  APLs  per  TOA? 

What  is  the  time  frame  SPAWAR  recommends  per  UIC? 

6.  In  addition,  in  order  to  utilize  the  Automated  Shore  Interface  (ASI),  which  provide 
automatic  electronic  data  transfer  to  the  activity  via  the  SCLSIS  loop,  the  licensing 
fees  are  also  involved. 

7.  Data  updates  to  the  WSF  are  fed  through  the  SLCSIS  loop  using  OMMS.  The  only 
path  to  feed  the  WSF  is  to  utilize  OMMS.  Currently  OMMS  is  not  used  by  the  NCF. 
NCF  uses  a  NCF  unique  MicroSnap  module  -  Maintenance  and  Operations  Support 
System  (MOSS)  (see  MicroSnap  MOSS  timeline  below). 

a.  1 992  -  CESO  initiates  a  study  to  determine  if  the  NCF  should  go  to  a  standard 
Navy  maintenance  system  (OMMS/3M)  or  COTS/GOTS  system. 

b.  1994  -  CESO/CBC  Gulfport/NAVMASSO  meeting  decides  3M  is  not  applicable 
and  not  an  effective  way  to  perform  vehicle  maintenance 

c.  Nov  1994  -  CESO  sends  requirements  to  NAVMASSO  requesting  cost  estimate 

d.  Jun  1 995  (9  months)  -  NAVMASSO  sends  cost  estimate 

e.  Sep  1 995  (3  months)  -  CESO  contracts  with  NAVMASSO  to  produce  a  Seabee 
“3M”  module 

f.  Jul  1 996  (10  months)  -  SPAWAR  accepts  project 

g.  Nov  1 996  (4  months)  -  CESO  funds  project  ($200,000) 

h.  Mar  1 997  (4  months)  -  first  development  planning  meeting 

i.  May  1997  (2  months)  -  functional  analysis  meeting 

j.  Sep  1 997  -  Jun  1 999  (21  months)  -  MOSS  developed 

k.  Jul  2000  (13  months)  -  production  installation  (4  years) 

Tasking  4.1b  Field  Level  TOA  Management  System 

1 .  SRS  was  completed  in  Fall  2000  and  distributed  to  the  functional  users  for 
comments.  On-site  review  with  functional  users  was  completed  by  2NCB  in  Nov 
2000.  The  SRS  is  a  good  starting  point  for  defining  the  requirements  for  developing 
a  field-level  TOA  management  system.  SRS  was  developed  to  address  the  needs 
of  the  SKs  managing  the  TOA.  Current  business  practices  dictate  the  SKs  are 
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responsible  for  the  approximately  60%  of  the  TOA.  It  is  unclear  how  much  input  the 
“other  operators”  have  provided.  Recommend  that  battalion  TOA  operators,  e.g. 
MLO,  CTR,  ARP  personnel  review  for  potential  additional  requirements. 

MicroSnap  TOAMS,  as  currently  proposed,  will  be  built  on  a  “standard  Navy  Supply 
System.”  However,  its  implementation  will  result  in  yet  another  NCF  unique  and  specific 
solution.  The  management/  maintenance/upgrades  will  be  the  unique  financial  and 
requirements  responsibility  of  the  NCF.  Furthermore,  it  has  been  agreed  MicroSnap 
has  a  finite  life,  due  to  other  NAVSUP  initiatives  such  as  R-Supply  and  ERP.  With 
TOAMS  being  a  NCF  unique  solution,  migration  to  a  future  system  will  likely  require 
additional  funding  by  NAVFAC  to  implement.  With  the  NCF  being  such  a  small  portion 
of  the  Navy  Supply  System,  the  anticipated  migration  to  the  future  system  may  be  lost 
until  larger  platforms  are  converted. 

a.  Does  not  utilize  open  database  structure 

b.  Relies  on  other  portions  of  MicroSnap  being  implemented 

■  SFM  (Supply  and  Financial  Management)  is  used  at  battalion  level  for 
purchasing  supplies 

■  OMMS  (Organizational  Maintenance  Management  System)  provides 
organizational  level  maintenance  and  is  not  currently  employed  by  NCF 
units,  with  no  active  plans  to  implement. 

■  SMS  (System  Management  Subsystem)  maintains  site  configuration  and 
user  access;  the  backbone  of  all  MicroSnap  applications  and  must  be 
present  for  any  module  to  run,  therefore  it  is  installed  and  operational  at  all 
MicroSnap  SFM  sites. 

■  MOSS  (Maintenance  and  Operations  Support  System)  manages  vehicle 
inventory,  maintenance,  and  operations;  schedules  preventive  and 
corrective  maintenance;  interfaces  with  SFM,  only  if  operating  on  the  same 
hardware,  i.e.  PC  workstation  or  LAN. 

■  CTS  (Custody  Tracking  System)  automates  the  issue/return  process;  works 
in  conjunction  with  SFM.  It  is  currently  available  at  3NCB  TOA  manager 
and  Gulfport  TOA  managers.  CTS  is  not  currently  used  by  battalions. 
However,  CTS  could  be  used  to  manage  augment  tools,  since  they  are  not 
managed  in  a  hierarchical  structure. 

■  APEX  allows  wed  viewing  of  MicroSnap  information.  Must  use  MicroSnap 
Windows  to  use  APEX.  The  Windows  version  is  currently  being  beta  tested 
at  2NCB.  There  is  a  one-time  only  cost  to  initialize  use  of  APEX.  The  cost 
is  unknown. 

2.  Costs  to  develop  MicroSnap  TOAMS  were  estimated  by  SPAWAR  at  $750,000,  and 
a  timeline  of  18  months.  This  estimation  was  considered  conservative,  and  due  to 
revision  once  the  final  SRS  is  accepted.  Draft  POA&M  has  been  completed.  The  final 
version  will  be  completed  after  the  SRS  is  accepted.  Past  performance  of  SPAWAR 
developing  NCF  solutions  should  be  considered.  2NCB  funded  SPAWAR  to  develop 
the  SRS  in  July  1999.  Current  anticipated  completion  date  is  CY  2001 . 

Why  are  we  not  using  an  open  database  for  TOA  management? 
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Why  are  there  unique  requirements  for  force-level  TOA  and  field-level  TOA 
management  systems?  Are  there  any  restrictions  from  preventing  a  single  solution? 

Tasking  4.2  MOSS-OMMS  link 

No  interface  currently  exists  between  MOSS  and  OMMS  to  complete  the  SCLSIS 
loop.  There  is  no  time  or  cost  estimates  for  this  link  at  this  time. 
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APPENDIX  L 


Meeting  Minutes:  WSF/CDMD-OA  Conference 
24  October  2000 

Meeting  was  held  at  0800,  24  October  2000  in  Room  G200/201  at  NFESC  Bldg  1100 
Port  Hueneme,  CA. 

Attendees: 

Craig  Sheesley,  NAVICP-M 
Steve  Santos,  NAVICP-M 
Rob  Johnston,  NFESC 
Anne  Lyons,  NFESC 
Dave  Schuelke,  NFESC 
LCDR(s)  Shawn  Cullen,  CBCHUE 
Don  Curtis,  CBCHUE 
Dave  Winn,  CBCHUE 

ISSUES: 

Can  the  Weapon  Systems  File  be  modified  to  accommodate  the  hierarchical  structure  of 
the  NCF  TOA? 

Can  configuration  management  of  field  level  TOA  be  implemented  through  the  use  of 
the  Weapons  System  File  (WSF)? 

DISCUSSIONS: 

1 .  The  “WSF”  is  actually  two  sets  of  databases  -  WSF  and  Configuration  Data 
Management  Database  -  Open  Architecture  (CDMD-OA) 

2.  WSF  is  maintained  by  NAVICP-M.  WSF  database  is  divided  into  three  separate 
database  files  -  Level  A,  Level  C,  and  Master  Item  File  (MIF): 

Level  A  -  relates  Ship  Unique  Identifier  Code  (UIC)  to  Allowance  Parts  List  (APL) 
or  Allowance  Equipage  List  (AEL) 

-  contains  the  ship’s  configuration  data 

Level  C  -  relates  APL/AEL  to  parts 

-  contains  equipment  configuration  and  technical  data 

MIF  -  relates  NUN  to  APL/AEL 

-  contains  item  management  data 

3.  WSF  is  an  asset  tracking  database  only 


Elizabeth  Collins,  CBCHUE 
Judy  Totten,  CBCHUE 
Ruben  Frutos,  CBCHUE 
Art  Quilantang,  CBCHUE 
SKCS  Leandro  Senores,  31st  NCR 
Sonia  Murphy,  EFDSW 
Debbie  Schultzel,  NITC 
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4.  CDMD-OA  database  is  central  repository  for  configuration  management  data: 


a.  Updated  electronically  by  CDM  via  MicroSnap  OMMS  module  which 
automatically  updates  WSF  Level  C,  updates  Level  A  every  two  weeks 

b.  Hierarchical  Structure  Code  (HSC) 

-  1 2-digit  code,  functionally  identifies  the  equipment  within  the  system 

-  First  five  digits  based  on  the  Expanded  Ship  Work  Breakdown  Structure 
(ESWBS) 

-  Relates  directly  to  an  APL/AEL  number 

5.  APL/AEL  is  the  common  data  field  between  the  WSF  and  CDMD-OA 

a.  Allowance  Parts  List  is  a  listing  of  parts  required  to  repair/maintain  equipment  in 
the  field;  the  APL  is  computed  using  FLSIP  Model  and  3-M  maintenance  data 

b.  Allowance  Equipage  List  is  a  listing  of  parts  required  for  a  piece  of  equipment  to 
function/perform;  all  items  must  be  provided 


CONCLUSIONS: 

Can  the  Weapon  Systems  File  be  modified  to  accommodate  the  hierarchical 
structure  of  the  NCF  TOA? 

The  NCF  should  be  able  to  utilize  the  WSF  and  the  CDMD-OA.  The  following  points 
should  be  considered  for  feasibility: 

-  Install  MicroSnap  OMMS  at  CBCHUE  for  Configuration  Data  Managers 

-  Install  MicroSnap  OMMS  at  the  field  level 

-  Code  the  TOA  Hierarchical  Structure  to  fit  the  HSC  (see  figure  1) 

-  Investigate  use  of  computer  script  to  automatically  develop  hierarchy  codes  vice 
human  effort 

-  Investigate  possibility  of  MicroSnap  TOAMS  as  database  for  field  unit 
requirements 

-  Investigate  use  of  WSF  “Planned  Adds”  with  the  same  HSC  as  “Installed  HSC; 
theoretically  requirements  may  be  compared  to  assets 

Can  configuration  management  of  field  level  TOA  be  implemented  through  the 
use  of  the  Weapons  System  File  (WSF)? 

The  NCF  should  be  able  to  manage  the  configuration  of  field  level  TOA  by  developing 
AELs  for: 


-  TOA  Assemblies 

-  TOA  Kits 
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-  Communications  gear 

-  Weapons 

-  Field  repairable  items 


TOA  Hierarchical  Structure 

Component  P25M 

Hierarchical  Structure  Code 

ESWBS 

XXXXX 

Sub-Component 

P25MC1 

XXXXX 

1 

Section 

14 

XXXXX 

1 

1 

4 

Group/Facility 

01431MC 

XXXXX 

1 

1 

4  1 

2 

Assembly/ 
Equipment  Code 

02012 

XXXXX 

1 

1 

4  1 

2  1  lt=> 

CDMD-OA 


APL/AEL 


l 

WSF 


Line  Item  1240-01-207-5787 


Figure  1.  Example  of  TOA,  CDMD-OA  and  WSF  Relationship. 
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Notes  from  MicroSnap  Conference 
07  Nov  00 


Attendees: 


Don  Curtis,  CBCHUE  Code  N6 
Dave  Winn,  CBCHUE  Code  N6 
Anne  Lyons,  NFESC  Code  32 
Katy  Lunsford,  NFESC  Code  32 
Dave  Schuelke,  NFESC  Code  221 


SKCS  Senores,  31st  NCR  R41C 
Judi  Takahara,  CBCHUE  Code  N6 
Brian  Garrigan,  SPAWAR  Code  91 
Mark  Anderton,  SPAWAR  Code  90 


There  are  600  people  at  Space  and  Naval  Warfare  Systems  Command,  Chesapeake  Division. 
SPAWAR  is  primarily  responsible  for  non-tactical  support  systems  for  supply  and  admin 
systems  afloat  and  ashore  -  surface,  subsurface,  aviation,  ground;  cradle  to  grave  support  - 
design,  development,  implementation,  life  cycle  support.  MicroSnap,  NALCOMIS,  NCTSS, 
ATLASS  D+  are  some  of  their  programs,  products. 

Funding  to  SPAWAR  is  reimbursable  from  customers  (including  CNET).  Normally,  they  develop 
a  product  for  a  customer  but  if  we  could  get  together  with  SPECWARCOM,  perhaps  we  could 
share  costs  with  them. 


ORGANIZATIONAL  MAINTENANCE  MANAGEMENT  SYSTEM  (OMMS)  -  DOS  based 

OMMS  system  manages  the  organizational  level  equipment  configuration,  equipment 
maintenance,  and  logistical  support  data.  Integral  part  of  SCLSIS  loop.  Feeds  data  to  the 
Configuration  Data  Manager  (CDM)  to  CDMD-OA  to  WSF.  Automates  the  3M  (Maintenance 
and  Material  Management)  tracking  and  reporting  system  using  2K  and  CK  forms.  3M  is  the 
maintenance  portion  of  OMMS  and  is  administered  by  NAVSEA  04.  OMMS  NG  (new 
generation)  will  replace  old  OMMS  program  under  SNAP  and  is  used  in  NCTSS. 

Equipment  Configuration 
Equipment  Maintenance  Management 
Logistics  Support  Data  Management 
SCLSIS  Loop 

Automated  Shore  Interface  (ASI)  updates  from  the  CDM  are  loaded  into  MicroSNAP 
Interfaces  -  OMMS  interfaces  with  SFM;  allows  parts  to  be  ordered  by  NSN  or  part 
number 


Discussion 

OMMS  feeds  data  through  the  SCLSIS  loop  via  2K  or  CK.  A  2K  is  opening  a  job  against  the 
equipment  (work  order).  A2K  relates  directly  to  an  ERO  in  MOSS.  Changing  brake  shoes  on  a 
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truck  is  an  example  of  a  2K.  A  CK  is  an  actual  part  change  or  a  new  part  e.g.  deleting  one  part 
and  adding  another.  A  brand  new  model  of  a  brake  shoe  uses  a  CK. 

MOSS  is  not  capable  of  reporting  anything  into  the  CDMD-OA.  That  is  all  locally  kept  info. 
Terms  (words)  describing  OMMS  and  MOSS  may  be  different  but  yet  describe  the  same 
process.  SKCS  Senores  says  we  need  a  meeting  to  determine  what  OMMS  cannot  provide. 
MOSS  and  OMMS  are  starting  to  merge. 

Determine  what  information  from  systems  development  is  required  to  implement  MOSS/OMMS 
link.  We’ve  already  spent  a  lot  of  money  getting  this  info;  how  can  we  take  advantage  of  what 
we  already  have  in  MOSS  without  reinventing  the  wheel?  Answer  is  more  on  the  data  elements 
than  on  the  equipment  side.  Place  CESE  equipment  in  OMMS  but  keep  it  also  in  MOSS  so 
people  will  not  see  as  big  a  change.  This  isn’t  the  most  efficient  way  to  do  this  but  probably  the 
most  practical. 

CDM  is  responsible  for  equipment  configuration.  Analysis  of  maintenance  data  falls  under 
NAVSEA  responsibility.  NCF  may  require  a  separate  CDM  for  each  unit  in  the  field,  and 
possibly  a  counterpart  at  each  brigade.  Each  NMCB  is  not  the  same  just  as  each  ship  in  the  same 
class  is  not  the  same.  UIC  stays  at  the  deployment  site.  When  a  battalion  goes  to  a  specific  site 
(say  Rota)  a  site  UIC  is  used  in  addition  to  the  Battalion  UIC. 


SUPPLY  FINANCIAL  MANAGEMENT  (SFM)  -  DOS  based 

SFMs  on  ships  use  OMMS.  CMs,  GMs,  and  ITs  use  OMMS  in  Seabee  battalions.  SFM 
automates  management  of  material  requirements,  requisition,  receipt,  inventory,  and  financial 
accounting  functions.  Adheres  to  NAVSUP  P-485  requirements.  Provides  some  supplemental 
data  based  on  the  customers  indiviual  requirements.  Transmits  data  via  DAMES,  DAAS, 
SALTS,  STARS-FL. 

Requirement,  Requisition  and  Receipt  Management 

Once  SFM  becomes  windows  based,  complete  ERO  process  will  be  automated 
through  MOSS/SFM.  Prototype  of  windows  based  SFM  starts  this  next  Monday  (13 
Nov)  and  will  be  available  90  days  later.  MOSS  feeds  data  into  SFM.  SFM  does  not 
feed  data  back  into  MOSS.  Won’t  have  to  go  to  SFM  to  determine  status.  58  sites 
will  be  using  MOSS.  At  a  major  deployment  site,  there  could  be  four  or  five  different 
users. 

Inventory  Control  Management 
Financial  Management 
Interfaces 

SFM  interfaces  with  OMMS  via  ASI,  APL/COSAL,  SEAS  reporting. 

Discussion 

SFM  future  enhancements  include  reimbursable  control  codes  and  standard  document  numbers. 


M-2 


MAINTENANCE  AND  OPERATION  SUPPORT  SYSTEM  (MOSS)  -  Windows  based 


There  is  no  APL  data  in  MOSS.  The  functionality  could  be  placed  in  MOSS  if  needed.  MOSS 
manages  vehicle  inventory,  maintenance,  and  operations  of  CESE.  MOSS  does  for  CESE 
equipment  what  OMMS  does  for  non-CESE  equipment.  MOSS  key  benefits  includes  managing 
vehicle  inventory,  vehicle  maintenance,  operations,  schedules  preventive  maintenance,  flexible 
configuration,  and  role-based  user  access.  MOSS,  OMMS,  and  SFM  will  work  together  in  any 
combination. 

Equipment  Configuration  Data 
Dispatch  Operations 
Reports  (On-line  or  printed) 

Manage  Direct  Turnover  (DTO)  Parts 
Maintenance  Supervisor  Review 
Off- site  data  exchange 

The  intention  of  the  downloaded  ERO  data  was  to  provide  a  historic  reference  of 
what’s  been  done.  Historical  data  cannot  be  updated  to  enter  missed  data. 

Discussion 

R46  currently  has  two  stand-alone  applications  according  to  Judi.  Two  separate  offices  perform 
maintenance  and  operations  of  CESE  equipment.  R46  is  done  at  the  end  of  the  Ethernet  line. 
They  have  poor  conductivity  and  routing  is  a  problem.  They  go  off-line  frequently.  Data  is 
transferred  to  a  diskette  or  other  electronic  file  and  transported  to  the  other  office.  When  at  a 
deployed  site,  there  may  be  only  two  laptops  and  connectivity  to  main  site  may  not  be  available. 
R46  maintenance  is  connected  to  a  LAN. 

Are  component  substitutes  available?  Not  through  SFM. 

Detach  and  deploy  a  subset  of  equipment  will  be  a  future  enhancement.  Additional  future 
enhancements  will  be  discussed  at  a  users  group  meeting  this  month. 

CUSTODY  TRACKING  SYSTEM  (CTS)  -  Windows  based 

Automates  the  issue,  turn-in  and  custody  processes  using  both  CTS-unique  data  and  data  from 
MicroSNAP  SFM 

Functions 

Individual  custody  records 
Issues  and  turn-ins 
Financial  reports 
Master  templates 
Import/export  custody  records 
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Interfaces 

CTS  interfaces  with  SFM 

Discussion 

Future  enhancements  include  interface  with  MicroSnap  TOAMS  and  ad-hoc  query. 
Navairwarcen  Pax  River  (AIT  for  Navy)  has  a  contract  for  SPECWAR  to  determine  an  inventory 
system  with  bar  coding. 

CTS  and  TOAMS  are  not  related;  use  both  at  the  same  time.  CTS  can  be  used  to  track  augment 
tools. 


TABLE  OF  ALLOWANCE  MANAGEMENT  SYSTEM  (TOAMS)  -  Windows  based 

Implementation  timeline  for  TOAMS  is  not  available  -  a  conservative  estimate  18  months  and 
$750,000.  TOAMS  draft  software  requirements  specification  (SRS)  has  been  developed. 
Visited  Camp  Moscrip  to  observe  business  practices.  Reviewed  existing  software  (ABFC  view, 
SAMMS/ILO).  Questioned  representatives  of  the  Seabee  community.  Draft  SRS  being 
reviewed  by  2NCB.  Draft  POA&M  developed,  will  be  finalized  after  approval  of  SRS. 

Functions 

Viewing  of  TOA  and  ABFC 
Maintain  TOA 
Maintain  augment 
Excess/shortage  maintenance 

Discussion 


TOA  is  actually  deployed  at  the  site.  ABFC  is  missing  sequence  (assembly/facility)  numbers. 

TOAMS  will  have  the  ability  to  track  home  site  equipment  as  well  as  track  a  detached  subset  of 
the  TOA. 

The  ability  to  repack  equipment  is  needed  since  original  packing  may  not  be  available  or  in  good 
condition.  ALS  has  different  packing  scenarios.  There  is  a  proposed  interface  between  ALS  and 
TOAMS;  TOAMS  talks  to  MicroSnap.  Master  (original)  packing  data  should  be  with  TOAMS 
which  gets  the  location  of  equipment  within  a  container  location  from  ALS. 

MOSS  maintains  CESE  equipment.  OMMS  data  is  not  visible  within  TOAMS. 
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APEX  -  Internet  based 


Intranet/intemet-based  centralized  data  repository  providing  claimancy-wide  query  capability 
Microsnap  is  an  end-user  product  of  APEX 

Discussion 

Seabee  community  will  control  access;  not  SPAWAR.  Foxpro  is  database.  Should  be  available 
early  next  year. 


GENERAL  DISCUSSION 

MicroSnap  will  run  on  a  stand-alone  pc,  lan,  or  regional  system.  There  are  over  300  customers 
using  MicroSnap.  MicroSnap  was  originally  designed  from  SNAP  II  for  customers  who  didn’t 
have  the  equipment  to  run  the  Navy  Tactical  Command  Support  System  (NTCSS)  suite,  which  is 
a  client  server. 

MicroSnap  may  not  be  useful  eight  years  down  the  road.  Everyone  may  be  required  to  migrate 
to  the  NTCSS  suite. 

3M  SKED  is  a  separate  program  developed  by  NAVSEA. 

SPAWAR  does  not  have  a  standard  costing  scheme  across  all  programs;  can  offer  the  whole 
range  of  services.  We  should  come  to  an  agreement  that  we  will  support  the  program  once 
implemented.  We  should  not  to  go  into  production  until  a  business  agreement  has  been  reached. 
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APPENDIX  O 


Lessons  Learned:  Total  Asset  Visibility  Project  (now  TOAMS) 


Background . 1 

AREAS  RESEARCHED/DEVELOPED: . 2 

EFFORTS  RATED: . 3 

ALS . 3 

Cubiscan . 3 

PBCRs . 4 

MicroSNAP  ALT  (Now  MicroSNAP  TOAMS) . 4 

Palm  nix . 5 

APEX . 5 

Other  Government  Software . 6 

Overview  Of  Automated  Systems  And  Capabilities . 6 

JOPES . 6 

Joint  Operations  Planning  and  Execution  System . 6 

TC-ACCIS . 7 

Transportation  Coordinator-Automated  Command  and  Control  Information  System 

. 7 

TC-AIMS  II . 7 

Transportation  Coordinators’  Automated  Information  for  Movement  System  E  ..  7 

DAMMS-R . 8 

Department  of  the  Army  Movements  Management  System-Redesigned . 8 

Automated  Air  Load  Planning  System . 8 

GTN . 8 

Global  Transportation  Network . 8 

AIT . 9 

Automated  Identification  Technology . . . 9 

Bar  Codes . 9 

Radio  Frequency  Identification  (RFID)  tags . 9 

Optical  Memory  Cards . 10 

Satellite-Tracking  Systems . 10 

LOGAIS . 11 

MDSSE . 11 

CALMS . 11 


Background 

This  Lessons  Learned  covers  the  period  from  August  1998  to  the  present  (November  2000).  The 
absence  of  asset  visibility  at  our  deployed  sites  had  become  the  focus  of  attention  in  August 
1998.  The  bulk  of  the  assets  are  contained  in  a  battalion’s  Table  of  Allowance  (TOA).  This 
compromised  efforts  to  manage  assets  and  provide  total  accountability.  2NCB  initiated  Total 
Asset  Visibility  (TAV)  efforts  by  attempting  to  capture  the  needed  information  into  MicroSNAP. 
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This  first  effort  failed  because  the  data  structure  required  to  reflect  the  TOA’s  hierarchal 
structure  could  not  be  duplicated  in  the  then  current  version  of  MicroSNAP. 

The  concept  of  visibility  expanded  to  encompass  accountability  and  thus  the  term  Total  Asset 
Accountability  (TAA).  In  time  TAA  as  it  applied  to  NMCB  TOAs  took  on  the  more  NCF 
specific  title  of  TO  A  Management  System  or  TO  AMS.  TO  AMS,  more  than  a  philosophy  of 
asset  accountability  focused  on  field  management  and  accountability  of  in-use  assets. 

During  Calendar  year  1999  TO  AMS  development  was  dedicated  largely  to  finding  and  testing 
new  technology  to  support  our  requirements.  Software  and  hardware  tested  were,  APEX 
(SPA WAR),  MicroSNAP  alteration,  Advanced  Loading  System  (ALS),  Cubiscan,  3Comm’s 
Palm  computing  platforms  with  scanning  capability  (PalmEx). 

“TO AMS  2005”  was  an  idea  of  how  a  variety  of  current  hardware  might  work  together  to 
perform  some  tasks  if  they  could  interface  with  a  larger  system.  That  larger  system  was  not 
addressed  in  “TOAMS  2005”.  The  source  documentation  for  this  idea  is  a  Power  Point 
Presentation  of  the  same  name. 

The  Seabee  Logistics  Center  created  a  web  accessible  asset  visibility  map  that  reflected  NCF 
assets  worldwide.  At  that  same  time  a  Computer  Aided  Design  (CAD)  style  three-dimensional 
(3D)  display  of  packed  assets  (that  is  of  CB  material  in  an  ISO  container)  was  considered  very 
useful  in  asset  management.  The  intent  was  to  provide  the  CB  in  the  field  enhanced  visibility  of 
assets,  right  down  to  where  it  was  in  a  sealed  ISO  container  and  to  provide  feed  back  on  asset 
location  to  this  asset  visibility  map. 

It  was  this  vision  that  led  the  team  to  research  visually  diagramed  asset  packing  and  movement 
programs.  Typically  these  products  either  focused  on  In  Transit  Visibility  (ITV)  or  creation  of 
packing  plans  based  on  cube  and  weight,  not  dimensions  and  loading  orientation.  Others 
produced  pictures  as  dictated  by  the  user.  We  found  one  that  would  take  the  raw  information 
about  the  material  to  be  packed  and  tracked  and  produce  visual  (3D)  loading  plans,  and  asset 
tracking,  ALS.  (ALS  is  in  use  by  a  number  of  large  corporations,  for  example  FedEx.  ALS 
provides  FedEx  with  ITV  and  load  plans  on  the  fly  among  other  practical  and  administrative 
features.) 

AREAS  RESEARCHED/DEVELOPED: 

ALS: 

APEX 

MicroSNAP  Alteration: 

Cubiscan: 

Portable  Bar  Code  Readers  (PBCR): 

Palm  devices 

Other  Government  Software 
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EFFORTS  RATED: 

ALS 

This  software  created  loading  plans  for  any  variety  of  conveyance  platforms  (Bulk  20  containers, 
463L  pallets,  TRIcons,  ect. .  .).  It  was  necessary  to  provide  the  program  with  the  weight  and 
dimensions  of  the  items  to  be  loaded.  The  user  could  set  a  variety  of  restrictions  and  keep 
together,  keep  apart  rules,  loading  orientation,  loading  sequences  and  preferred  container  type. 

The  software  performed  wonderfully,  exceeding  my  expectations.  It  followed  all  the  rules  we  set 
for  it,  balanced  the  container  and  slightly  reduced  the  number  of  containers  we  expected  to  use. 
The  loading  diagrams  were  easy  to  read 

ALS  will  be  more  useful  to  the  military  if  it  is  integrated  into  some  sort  of  a  data  warehouse. 
During  the  test  of  ALS  the  dimensional  data  for  the  Bravo  pack-up  was  recorded  on  excel 
spreadsheets.  These  sheets  were  created  for  ease  of  reading  and  not  with  data  integrity  or 
database  structure  in  mind.  So  the  most  challenging  part  of  the  ALS  test  was  converting  the 
spreadsheets  into  something  the  program  could  understand.  This  “data  massaging”  process 
would  be  avoided  if  the  information  were  already  being  kept  in  an  inventory  management 
software  like  MicroSNAP 

Drawbacks:  ALS  did  have  trouble  with  smaller  containers  and  flat  racks.  In  the  Bravo  pack-up 
test  it  was  necessary  to  visually  review  and  change  many  of  the  recommended  scenarios.  The 
software  does  allow  for  this.  It  was  not  used  for  configured  containers. 

Recommendation:  I  believe  that  ALS  would  aid  individuals  creating  Master  Packing  Plans  and 
impromptu  packing  plans  for  mount  out  or  limited  cargo  movement  in  exactly  the  same  way  that 
an  adding  machine  aids  an  accountant.  It  does  not  replace  the  knowledge,  intuition  or  experience 
of  load  planners  but  it  can  save  them  considerable  labor.  Considering  that,  I  would  like  to  see  it 
interfaced  with  the  appropriate  data  sources  and  available  to  SLC  and  embark  personnel  for  their 
use. 

Cubiscan 

The  Cubiscan  by  Quantronics  is  a  device  that  weighs  and  measures  objects  and  records  that 
information  automatically.  It  can  feed  the  information  into  any  number  of  software  applications 
and  works  with  scanners  easily.  It  required  little  training. 

My  evaluation  of  this  is  that  it  has  value  only  in  an  industrial  warehouse,  placed  in  an  assembly 
line  setting.  Used  there  it  could  establish  and  keep  current  a  baseline  of  dimensional  data  on 
items  at  the  NSN  level. 

I  do  not  see  its  utility  for  the  larger  boxes.  It  is  faster  to  hand  measure  kit  and  facility  boxes  than 
it  is  to  move  the  box  to  the  cubiscan.  A  second  draw  back  is  that  each  series  of  the  cubiscan  can 
handle  packages  only  within  certain  limited  weights  and  dimensions.  The  larger  ones  won’t 
“see”  a  small  item  and  the  smaller  cubiscans  cannot  accommodate  a  large  package.  To  measure 
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all  of  the  TOA  all  three  size  machines  would  need  to  be  present,  and  even  at  that  the  largest  and 
heaviest  items  would  still  not  fit. 

My  recommendation  is  to  have  one  of  the  100  series  on  the  assembly  line  at  the  CBCs,  strictly 
for  the  purpose  of  measuring  the  line  items.  I  would  not  deploy  these  to  a  camp,  DFT  or  det. 
The  information  collected  should  be  fed  back  to  Item  managers. 

PBCRs 

We  did  very  little  direct  testing  of  Portable  Bar  Code  Readers.  We  did  use  and  were  happy  with 
the  PALM  El  scanner  and  a  keyboard  emulator  called  Wasp.  PBCRs  are  a  very  straightforward 
decision.  There  are  a  variety  of  bar  code  readers  that  can  interface  with  any  number  of  software 
applications.  A  user  can  pick  and  choose  the  best  device  for  the  environment,  task  and  worker. 
The  range  runs  from  very  small  wands  and  pens  to  Palm  computing  platforms,  to  large 
ruggedized  guns  with  RF  transmission. 

Conclusion:  We  need  AIT;  PBCRs  are  well  established,  familiar  to  most  users  and  widely 
available.  AIT  should  be  implemented  at  any  data  collection  point  practicable. 

MicroSNAP  ALT  (Now  MicroSNAP  TO  AMS) 

The  alteration  to  MicroSNAP,  briefly,  is  a  change  to  its  inventory  capability.  Historically 
MicroSNAP  could  not  accurately  reflect  TOA  assets  because  of  the  unique  nature  of  the  TOA’s 
hierarchy  that  is  needed  for  line  item  data  to  be  meaningful  and  the  more  elaborate  storage  (or 
“in  use”)  location  requirement. 

Altering  the  inventory  system,  or  rather  adding  the  functionality  to  accommodate  these  two 
things,  is  the  core  of  the  alteration.  Ancillary  to  this  alteration  are  things  like  added  report 
capability,  allowances  based  on  a  TOA,  Embark  and  Packing  plan  generation  (via  CALM, 
CAEMS  and/or  an  ALS  type  of  application  that  is  to  be  imbedded  in  or  linked  to  MicroSNAP), 
visibility  to  ABFCView  data  from  SLC,  expanded/improved  AIT  and  others. 

The  MicroSNAP  TO  AMS  by  design  follows  these  guiding  principles: 

1 .  It  conforms  to  current  NAVFAC  conventions. 

2.  It  is  intended  to  provide  functionality  that  currently  does  not  exist. 

3.  It  should  be  able  to  share  /  exchange  data  where  such  requirement  exists  rather  than 
duplicate  it. 

4.  It  should  be  usable  by  ALL  TOA  holders,  not  just  an  NMCB  or  NAVFAC  unit. 

5.  The  requirements  are  derived  from: 

a.  NAVFAC,  NAVSUP  and  NAVSEA  instructions,  publications  and  manuals. 

b.  Other  related  instructions  (example  2/3NCBINST  4400.3) 

c.  Commonly  accepted  CB  cultural  practices. 

d.  Direct  observation  and  participation  in  the  involved  processes. 

e.  Interviews  /  open  communication  with  process  owners. 
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Conclusion:  The  basis  of  the  alteration  is  simple;  its  implementation  complex.  I  look  forward  to 
a  comprehensive  TOA  management  tool  in  this  alteration. 

NOTE:  An  important  point  of  clarification:  this  alteration  has  assumed  the  name  MicroSNAP 
TOAMS.  This  identification  is  recent.  It  is  not  the  TOAMS  2005  concept  broadly  advertised  in 
calendar  year  1999  until  February  2000.  These  two  distinct,  different  projects  developed  along 
different  lines  and  by  different  personnel. 

Palm  lllx 

Palm  pilot  like  devices  show  great  promise  for  future  utility  if  they  are  incorporated  into  a  larger 
information  system.  Otherwise  they  are  sophisticated  personal  organizers  but  of  little  use  to 
TOA  management. 

The  greater  power  in  the  palm  computing  devices  results  from  writing  small  programs  for  them. 
This  kind  of  effort  is  not  something  we  should  realistically  expect  of  most  sailors.  It  is  for  this 
reason  that  I  say  they  should  be  incorporated  into  a  larger  information  system. 

The  3com  platform  we  tested  cold  do  anything  a  basic  data  base  could  and  the  programming 
enabled  information  processing,  retrieval  and  even  collection  via  a  stylus,  scanner  or 
synchronization  with  another  computer. 

We  put  the  ABFC  view  data  into  it  and  wrote  a  3com  based  ABFCview  program  that  worked 
like  the  familiar  DOS  based  version.  We  also  put  one  core  of  the  Bravo  pack-up  into  the 
Palmlllx.  The  information  consisted  of  Facility,  Assembly,  Box  numbers,  Sequence  numbers, 
dimensions,  capability  set  and  packed  location. 

I  also  experimented  with  storing  large  text  files  for  reference  with  great  success.  The  Palm  in 
with  the  scanner  on  it  worked  very  well  and  scanned  accurately  every  test. 

In  conclusion,  the  Palm  computing  device  is  convenient,  versatile  and  powerful  if  properly 
programmed  and  linked  to  useful  information.  It  can  provide  multiple  functions  while  also  being 
a  PBCR  that  links  or  synchs  with  parent  application.  The  caveat  is  that  without  programming 
and  source  data  it  is  otherwise  a  sophisticated  personal  organizer  and  planner.  The  version  we 
tried  was  not  rugged  and  on  one  occasion  broke  beyond  repair  by  simply  dropping  it  once. 

APEX 

Apex  is  a  centralized  data  repository  providing  claimancy-wide  query  capability.  It  can  accept 
data  from  any  number  of  sources.  Currently  it  holds  MicroSNAP  data  and  3NCB  book  data. 

Our  trial  of  this  system  was  successful.  Because  MicroSNAP  held  only  limited  TOA 
information  at  the  time  of  the  test  we  found  no  immediate  use  in  TOA.  It  is  however  very  useful 
for  supply/financial  and  asset  management  and  has  been  used  by  the  SPECWAR  community  for 
several  years  now.  2NCB  will  use  it  in  FY01  for  supply/financial  and  TOA  visibility.  The  TOA 
portion,  yet  to  be  implemented,  is  an  interim  application  for  use  until  MicroSNAP  TOAMS  is 
operational. 
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CONCLUSION:  APEX  is  the  essential  link  between  CB  assets  in  the  field  (MicroSNAP 
TO  AMS)  and  visibility  of  those  at  the  brigades.  Its  extensive  query,  report  and  export 
capabilities  facilitate  complete,  accurate  analysis  of  any  question  or  subject.  It  alleviates  data 
calls  and  reporting  from  the  field. 

If  MicroSNAP  is  maintained  under  current  supply  disciplines  in  accordance  with  current 
instructions  and  applicable  publications  the  TOA  custodian  will  not  need  to  take  any  other  action 
in  order  to  have  full  visibility  and  accountability  at  the  local  and  brigade  level. 

Other  Government  Software 

Command  and  Control  Applications  Compendium  2000  is  available  at 

http://www.mcu.usmc.mil/ccss/CCSC/c2%20compendium/default.htm. 


Overview  Of  Automated  Systems  And  Capabilities 

TRANSPORTATION  RELATED  AUTOMATED  SYSTEMS  AND  CAPABILITIES 
There  are  a  number  of  transportation  related  command  and  control  (C2)  systems,  automated 
information  systems  (AISs),  and  automated  identification  technologies  (AITs)  designed  to  assist 
in  transportation  planning,  management  and  execution.  What  follows  is  a  description  of  selected 
systems  and  capabilities.  Where  applicable,  world  wide  web  (WWW)  locations  and  POCs  for 
systems/capabilities  have  been  included. 

JOPES 

Joint  Operations  Planning  and  Execution  System 

JOPES  is  the  integrated,  joint,  conventional  command  and  control  system  used  by  the  Joint 
Planning  and  Execution  Community  (JPEC)  to  conduct  joint  planning,  execution  and  monitoring 
activities.  JOPES  supports  senior-level  decision-makers  and  their  staffs  at  the  National 
Command  Authority  (NCA)  level  and  throughout  the  JPEC.  It  is  a  combination  of  joint  policies, 
procedures,  personnel,  training  and  a  reporting  structure  supported  by  automated  data  processing 
systems,  reporting  systems,  and  the  Global  Command  and  Control  System  (GCCS).  JOPES  is  a 
GCCS  application. 

During  peacetime  conditions,  JOPES  is  used  for  deliberate  planning  to  produce  OPLANs, 
CONPLANS,  and  concept  summaries.  In  crisis,  JOPES  is  used  for  Crisis  Action  Planning  (CAP) 
to  produce  OPORDs.  JOPES  facilitates  rapid  building  and  timely  maintenance  of  OPLANs, 
Concepts  of  Operation  (CONOPs),  and  concept  summaries.  In  CAP,  it  supports  rapid 
development  of  effective  options  and  OPORDs  in  no-plan  situations  or  when  existing  plans  must 
be  adapted.  JOPES  is  used  to  conduct  a  transportation  feasibility  analysis  after  the  CINC, 
supporting  CINCs  and  Service  components  develop  the  TPFDD.  It  supports  effective 
management  of  operations  in  execution  across  the  spectrum  of  mobilization,  deployment, 
employment,  sustainment,  and  redeployment  activities. 

The  Army  proponent  for  JOPES  is  the  DA  Deputy  Chief  of  Staff  for  Operations  and  Plans 
(DCSOPS),  Attn:  DAMO-ODO-M,  400  Army  Pentagon,  Washington  DC  20310-0400. 
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Telephone  is  DSN  224-0655/1614  or  commercial  (703)  614-0655/1614.  Overall  proponent  for 
JOPES  is  the  JS/J3. 


TC-ACCIS 

Transportation  Coordinator-Automated  Command  and  Control  Information  System 
The  TC-ACCIS  is  an  information  management  and  data  communications  system  that  Army  units 
(active  and  reserve)  use  to  plan  and  execute  deployments.  System  capability  includes  the  ability 
to  create  and  maintain  unit  movement  data,  prepare  convoy  requests,  create  military  shipping 
labels  and  other  movement  documentation,  and  preparing  vehicle  load  cards  and 
vehicle/container  packing  lists.  Principle  system  users  within  the  division  and  installation  are  the 
UMOs,  ITO,  UMCs,  and  IC-UMOs.  Selected  TC-ACCIS  functionality  will  migrate  to  TC-AIMS 

n. 

Units  maintain  their  AUEL  and  develop  their  DEL  using  TC-ACCIS.  TC-ACCIS  software 
resides  on  computers  at  the  nOs  of  CONUS  installations  and  nOs  or  movement  control  units  in 
overseas  theaters.  The  ITO,  using  the  central  computer,  will  consolidate  requirements  and 
transmit  equipment  lists  and  transportation  requests  to  systems  outside  TC-ACCIS.  For  example, 
CONUS  ITOs  transmit  AUEL  and  DEL  to  FORSCOM's  Computerized  Movement  Planning  and 
Status  System  (COMPASS)  data  base.  The  information  can  then  be  used  to  update  JOPES. 
Through  TC-ACCIS,  the  ITO  also  provides  MTMC  the  deployment  requirements  (such  as  DEL), 
domestic  routing  requests,  export  traffic  release  requests,  and  passenger  transportation 
requirements. 

Questions  concerning  TC-ACCIS  should  be  directed  to  PM,  TC-ACCIS;  9350  Hall  Road,  Suite 
142;  Ft  Belvoir  VA  22060-5526.  Telephone  is  commercial  (703)  923-1062. 

TC-AIMS  II 

Transportation  Coordinators’  Automated  Information  for  Movement  System  II 
TC-AIMS  II  is  a  joint  information  management  system  that  provides  functionality  for  facilitating 
the  movement  of  unit  personnel,  equipment,  and  supplies  during  peace  and  war,  and  provides 
visibility  data  of  those  forces  from  home  station  to  the  conflict  and  back.  Its  primary  mission  is 
to  support  the  warfighter  in  the  planning  and  execution  of  deployment,  sustainment,  and 
redeployment  of  forces  during  peace  and  war.  TC-AIMS  II  will  integrate  current  DOD 
transportation  systems  supporting  installation  and  unit  movement  requirements  into  a  single 
system. 

TC-AIMS  II  includes  functionality  found  in  three  separate  Service  legacy  systems:  the  Air 
Force’s  Cargo  Movement  Operational  System  (CMOS),  the  Army’s  TC-ACCIS,  and  the  Marine 
Corps  Transportation  Coordinator’s- Automated  Information  Management  System  (TC-AIMS). 
Planned  system  functionality  includes  providing  source  item  level  detail  information  on 
equipment  and  personnel  to  the  separate  Service  and/or  Joint  TPFDD  systems,  rail  loading  and 
convoy  planning/scheduling,  automated  Military  Standard  Transportation  and  Movement 
Procedures  (MILSTAMP)  documentation,  common  user  lift  requests  to  transportation 
component  commands  (TCCs),  creating  and  maintaining  unit  equipment  list  (UEL)/DEL,  and 
sharing  load  plan  information  with  air/ship  stow  planning  systems.  The  system  will  also  provide 
GTN  with  unit  movement  ITV  information  for  passengers  and  cargo.  TC-AIMS  II  is  currently  in 
prototype  development. 
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Questions  concerning  TC-AIMS  II  can  be  addressed  to  TC-AIMS  H-JPMO;  Attn:  SFAE-PS-TC; 
9350  Hall  Road,  Suite  142;  Ft  Belvoir  VA  22060-5526.  Telephone  is  DSN  656-0525  or 
commercial  (703)  806-0525.  More  information  is  available  on  the  TC-AIMS  II  home  page  at 
http://www.tcaimsii.belvoir.armv.mil. 

DAMMS-R 

Department  of  the  Army  Movements  Management  System-Redesigned 

DAMMS-R  provides  an  automated  movement  information  management  capability  to  movement 
managers  involved  in  providing  movement  control  and  allocation  of  common  user  land 
transportation  in  a  theater.  It  also  provides  theater  mode  operators  with  a  tool  to  assist  in  the 
management  of  their  assets,  including  personnel,  equipment,  and  terminal/trailer  transfer  points. 
The  system  has  a  financial  management  capability  to  assist  in  maintaining  records  and  payment 
for  commercial  movements.  DAMMS-R  consists  of  six  separate  but  interrelated  subsystems  used 
by  transportation  planners,  movement  managers,  mode  operators,  traffic  controllers, 
transshippers,  and  unit  movement  personnel.  These  subsystems  are  the  shipment  management 
module,  movement  control  team  operations  module,  mode  operations  module,  convoy  planning 
module,  highway  regulation  module  and  transportation  addressing  module. 

Currently  DAMMS-R  is  fielded  in  two  Blocks.  Block  1  includes  the  shipment  management, 
movement  control  team  operations,  mode  operations  and  transportation  addressing  modules;  and 
block  2  contains  the  highway  regulation  and  convoy  planning  modules.  DAMMS-R  Block  3  will 
replace  Block  1.  It  is  scheduled  for  initial  operational  capability  (IOC)  in  Mar  98  and  will  offer 
improved  functionality  for  the  modules  currently  in  Block  1.  Selected  DAMMS-R  functionality 
is  planned  for  migration  to  TACIMS-II. 

The  POC  for  DAMMS-R  is  PM-ILOG,  800  Lee  Ave,  Ft  Lee  VA  23801-1718.  Telephone  is  DSN 
687-60476646/6653  or  commercial  (804)  734-6047/6646/6653. 

AALPS 

Automated  Air  Load  Planning  System 

AALPS  provides  DOD  with  an  automated  information  system  to  support  the  process  and 
functions  of  aircraft  estimation,  aircraft  gross  load  planning,  deliberate  load  planning  and 
execution,  and  tracking  of  movement  statistics  during  deployments.  AALPS  reached  IOC  in  Apr 
97  and  over  400  systems  are  currently  fielded.  Selected  Computer  Aided  Load  Manifesting 
(CALM)  functionality  is  scheduled  to  be  available  in  AALPS  in  Mar  98,  with  the  CALM  system 
being  terminated  in  Jun  99.  AALPS  functionality  is  scheduled  for  migration  to  TCAIMS  H. 
AALPS  full  operational  capability  (FOC)  is  planned  for  Jul  99. 

Questions  concerning  AALPS  can  be  addressed  to  HQ  MTMC  Attn:  MTIM-AL,  Room  517, 
4040  N.  Fairfax  Drive,  Arlington  VA  22203.  Telephone  is  DSN  426-8205  or  commercial  (703) 
696-8205. 

GTN 

Global  Transportation  Network 

GTN  is  an  automated  command  and  control  information  system  that  provides  an  integrated  view 
of  transportation  information.  It  provides  USTRANSCOM  the  ability  to  perform  command  and 
control  operations,  planning  and  analysis,  and  business  operations  to  meet  customer 
requirements.  GTN  also  provides  ITV  for  the  defense  transportation  system  (DTS).  GTN  collects 
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and  integrates  transportation  information  from  selected  DOD  systems  for  use  by  transportation 
data  customers:  the  NCA,  CINCs,  USTRANSCOM,  and  the  Services.  The  system  provides  these 
users  the  ability  to  monitor  movement  of  forces,  cargo,  passengers,  and  patients  and  movement 
of  military  and  commercial  airlift,  sealift  and  surface  assets. 

GTN  achieved  IOC  in  Mar  97  and  is  available  in  both  WWW  and  client  server  applications.  The 
initial  operational  capability  contains  the  ITV  functionality.  The  command  and  control 
functionality  and  other  capabilities  are  scheduled  in  subsequent  deliveries  leading  to  the  planned 
GTN  FOC  in  Aug  99. 

The  GTN  Program  Management  Office  is  located  at  USTRANSCOM;  TCJ6,  Attn  GTNPMO; 
508  Scott  Drive;  Scott  Air  Force  Base,  IL  62225.  Telephone  is  DSN  576-2866  or  commercial 
(618)  256-2866.  The  POC  for  GTN  training  is  USTRANSCOM  J4-JTO,  DSN  576-8042  or 
commercial  (618)  256-8042.  The  POC  for  user  accounts  is  USTRANSCOM  J4-MSS,  DSN  576- 
8015  or  commercial  (618)  256-8015.  More  information  about  the  GTN  system  is  available  at 
http://wwwgtn.safb.af.mil/homepage/.  Additionally,  Appendix  A  provides  instructions  for 
obtaining  access  to  GTN. 

AIT 

Automated  Identification  Technology 

AIT  encompasses  a  variety  of  read  and  write  storage  technologies  that  capture  asset 
identification  information.  These  technologies  include  bar  codes,  magnetic  strips,  integrated 
circuit  cards,  optical  memory  cards  (OMCs)  and  radio  frequency  (RF)  identification  tags.  They 
are  used  for  marking  or  "tagging"  individual  items,  multipacks,  air  pallets,  and  containers.  AIT 
devices  offer  a  wide  range  of  data  storage  capacities  from  a  few  characters  to  thousands  of  bytes. 
The  devices  can  be  interrogated  using  a  variety  of  means  including  contact,  laser,  or  RF.  The 
information  obtained  from  the  interrogations  can  then  be  provided  electronically  to  automated 
information  systems.  AIT  includes  the  hardware  and  software  to  create  the  storage  devices,  read 
the  information  stored  on  them,  and  integrate  that  data  with  other  logistics  data.  AIT  also 
includes  the  use  of  satellites  to  track  and  redirect  shipments. 

Bar  Codes 

A  bar  code  is  an  array  of  parallel,  narrow,  rectangular  bars  and  spaces  that  represent  a  group  of 
characters  in  a  particular  symbology.  Bar  codes  are  applied  on  labels,  paper,  plastic,  ceramic,  and 
metal  by  a  variety  of  marking  techniques.  A  reader  scans  the  bar  code,  decodes  it,  and  transfers 
data  to  a  host  computer.  Within  DOD  and  the  Army  a  common  use  of  linear  bar  codes  is  the 
military  shipping  label  which  contains  the  transportation  control  number  (TCN)  and  other 
transportation  information.  In  the  future,  DOD  plans  to  phase  in  two-dimensional  bar  codes  for 
selected  areas  of  use.  Two  dimensional  bar  codes  have  a  greater  data  capacity  and  are  more 
durable  than  linear  bar  codes. 

Radio  Frequency  Identification  (RFID)  tags 

RFID  is  used  to  identify,  categorize,  and  locate  people  and  materiel  automatically  within 
relatively  short  distances  (a  few  inches  to  300  feet).  The  RFID  labels  are  known  as  tags  or 
transponders.  They  contain  information  that  can  range  from  a  permanent  ID  number 
programmed  into  the  tag  by  the  manufacturer  to  a  variable  128-kilobyte  memory  that  can  be 
programmed  by  a  controller  using  RF  energy.  The  controller  is  usually  referred  to  as  a  reader  or 
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an  interrogator.  An  interrogator  and  a  tag  use  RF  energy  to  communicate  with  each  other.  The 
interrogator  sends  an  RF  signal  that  "wakes  up"  the  tag,  and  the  tag  transmits  information  to  the 
interrogator.  In  addition  to  reading  the  tag,  the  interrogator  can  write  new  information  on  the  tag, 
thus  permitting  a  user  to  alter  the  tag’s  information  within  the  effective  range.  Interrogators  can 
be  networked  to  provide  extensive  coverage  for  a  system. 

The  Army  uses  an  active  RF  tag  that  accommodates  line-item  detail  information  to  provide  ITV 
and  stand-off,  in  the  box  visibility  of  container  contents.  As  an  example,  the  tag,  which  contains 
data  on  the  container  contents,  is  placed  on  the  container  and  then  read  as  it  passes  interrogators 
located  at  nodes  or  other  critical  locations  within  the  transportation  system.  RFID  capabilities 
provided  by  active  RF  tags  are  beneficial  when  a  user  needs  to  locate  and  redirect  individual 
containers.  RFID  may  also  be  used  in  an  austere  environment  where  there  are  inadequate 
systems  or  communications  infrastructure,  and  to  facilitate  the  AIS  capture  of  asset  data.  The 
active  RFID  capability  offers  significant  capabilities  for  yard  management,  port  operations,  and 
in-transit  visibility  (ITV).  The  United  States  Army  Europe  (USAREUR)  currently  use  RF  tags  to 
track  selected  cargo. 

Optical  Memory  Cards 

OMCs  use  the  optical  technology  popularized  by  audio  compact  disks  (CDs)  and  audio-visual 
CD-ROM  (read  only  memory)  products.  Although  users  of  those  products  can  write-once/read- 
many  (WORM)  times,  the  OMC  differs  in  that  information  is  written  to  the  card  in  increments 
rather  than  at  one  time.  An  OMC  can  have  data  written  to  it  in  a  sequential  order  on  many 
occasions  until  all  available  memory  has  been  used.  An  OMC  is  similar  in  size  to  a  credit  card 
and  can  be  easily  carried.  DOD  activities  use  OMCs  when  extensive  content  detail  is  required, 
such  as  for  multipack,  air  pallet,  container,  trailer,  and  rail-car  shipments.  The  Defense  Logistics 
Agency’s  Automated  Manifest  System  (AMS),  uses  a  DOD  standard  OMC.  The  primary 
objective  of  AMS  is  to  facilitate  automated  receipt  processing.  OMCs  are  used  best  when  a  data 
audit  trail  is  required  or  an  extensive  amount  of  data  has  to  be  stored. 


Satellite-Tracking  Systems 

A  satellite-tracking  system  provides  the  ability  to  track  the  exact  location  of  vehicles  and 
convoys.  The  latitude  and  longitude  locations  of  trucks,  trains,  and  other  transportation  assets 
equipped  with  a  transceiver  are  transmitted  periodically  via  a  satellite  to  a  ground  station.  Some 
systems  also  provide  two-way  communications  between  a  vehicle  operator  and  a  ground  station 
for  safety,  security,  and  rerouting. 

Satellite  tracking  uses  a  cellular  or  satellite-based  transmitter  or  transceiver  unit  to  communicate 
positional  information,  encoded  and  text  messages,  and  (in  the  case  of  sensitive  DOD  ordnance 
movements  in  the  CONUS)  emergency  messages  from  in-transit  conveyances  to  the  ground 
station.  Transceiver-based  technologies  also  permit  communications  from  a  ground  station  to  the 
in-transit  conveyance.  A  user  can  compose,  transmit,  and  receive  messages  with  small  hand-held 
devices  or  with  units  integrated  with  computers.  The  US  European  Command  (USEUCOM)  is 
using  satellites  to  track  convoys  and  critical  shipments  as  they  move  to  and  from  Bosnia. 

The  following  description,  using  USEUCOM  as  an  example,  clarifies  how  a  satellite-tracking 
system  works.  A  system  has  five  components:  a  subscriber  unit,  satellite,  earth  station,  network 
control  center  (NCC),  and  logistics  managers.  A  subscriber  unit  is  installed  on  the  conveyance 
being  tracked.  The  unit  exchanges  information  with  an  earth  station  via  satellite.  The  earth 
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station  is  connected  to  an  NCC  that  stores  information  in  electronic  mailboxes.  Logistics 
managers  access  their  mailboxes  to  receive  information  from  subscriber  units  and  return 
information  to  them. 

Questions  concerning  AIT  for  the  Army  can  be  addressed  to  DA  DCSLOG, 

US  Army  Logistics  Integration  Agency,  Attn:  LOIA-LS,  5001  Eisenhower  Ave,  Alexandria  VA 
22333-0001.  Telephone  is  commercial  (703)-6 17-4493  or  DSN  767-4493.  More  information  is 
available  on  AIT  at  WWW  site  http://lia.army.mil/ait/index.htm 

Their  home  page  is  also  recommended:  http://lia.armv.mil/ 

LOGAIS 

Logistics  Automated  Information  System 

Primary  Purpose:  A  family  of  systems  used  to  track  people,  supplies,  and  equipment.  The 
coordinated,  mutually  supporting,  personal  computer  based  programs  support  peacetime 
operations  and  immediate,  on-hand  crisis  action/time  sensitive  operational  and  logistics  planning 
and  execution  of  deployment  and  redeployment  of  MAGTF  and  NSE  in  independent,  joint  and 
combined  operations. 

Contains  Marine  Air  Ground  Task  Force  War  planning  System  13  (MAGTF  II),  MAGTF 
Deployment  Support  System  II  (MDSS  II),  Transportation  Coordinators'  Automated  Information 
Management  System  (TC  AIMS),  Asset  Tracking  for  Logistics  and  Supply  System  (ATLASS), 
Computer  Aided  Embarkation  Management  System  (CAEMS),  Automated  Identification 
Technology  (AIT),  and  the  MAGTF  Data  Library  (MDL). 

MDSS  II 

MAGTF  II  Deployment  Support  System  II  is  a  unit  database  and  all  of  a  unit’s  equipment 
resides  in  it.  It  does  allow  one  item  to  be  associated  with  other  items.  This  is  MDSS  H’s 
“Association”  function.  It  can  create  a  parent  for  an  NSN  level  item.  The  analogy  to  this  might 
be  understood  as  Assembly  to  NSN  or  APL  to  NSN.  The  systems  capability  stops  with  this 
single  level  of  association  and  is  therefore  incompatible  with  the  much  more  complex  TOA 
hierarchy  system. 

CALMS 

Computer  Aided  Load  Manifesting  System  Is  the  system  that  provides  an  interactive  graphics 
tool  for  producing  detailed  aircraft  load  plans  which  meet  aircraft  constraints  (less  commercial 
aircraft),  based  on  data  imported  from  MDSS  13.  Capability  has  been  used  as  standalone  program 
for  some  time. 
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